4.1 A Day in the Life of a Request

The best way to understand the internals of the request processing architecture in ASP.NET is to trace the path of a request from its initial entry into a server all the way to its ultimate dispatching to the ProcessRequest method of your Page class. We begin with a high-level overview of how requests are routed on a machine processing requests with ASP.NET, and then take a more detailed look at the internals of the pipeline.

4.1.1 Ten Thousand “Foot View of Request Processing

Typically, ASP.NET requests initiate from IIS. ^[9] When an HTTP request comes in from a client, typically on port 80, the IIS process ( inetinfo.exe ) receives the request and attempts to locate an extension mapping for the URL requested . If the request is for an ASP.NET page (it ends with .aspx), IIS loads the aspnet_isapi.dll ISAPI extension DLL and passes the request on to it. Once the aspnet_isapi.dll receives the request, it attempts to locate the ASP.NET worker process, housed in aspnet_wp.exe . If it is not running, it is started, and several named pipe connections are established between the ISAPI DLL and the worker process. Once these connections are established, the request is sent across a named pipe to the ASP.NET worker process for handling. Inside the worker process, ASP.NET routes the request to a designated AppDomain and dispatches it to the HTTP pipeline in that AppDomain . The end result of the request passing through the pipeline is the compilation (first time only) and creation of a class that implements the IHttpHandler interface, typically your Page -derived class. This handler acts as the endpoint of the request, populates the response buffer, and delivers the response back through the same channels it came from until IIS ends up sending back the response buffer. Figure 4-1 depicts this high-level view of request processing in ASP.NET.

^[9] It is possible to host ASP.NET using another mechanism for dispatching and processing requests. Microsoft has produced a sample called Cassini, which demonstrates hosting ASP.NET in a custom Web server application. For more details, see http://www.asp.net.

Figure 4-1. High-Level View of Request Processing in ASP.NET

4.1.2 Inside the Pipeline

Once the request makes it into the worker process, it goes through a series of steps and classes before it arrives at the ultimate handler. To begin with, each ASP.NET application is housed within an AppDomain in its worker process. AppDomains are a CLR construct that provides processlike memory and security isolation, without the overhead of actually creating separate processes. ASP.NET uses AppDomains to separate applications from each other so that if one application has a problem, it can safely be removed without affecting the remaining applications. Figure 4-2 depicts the various pipeline classes that live within an application's AppDomain and shows how they interact to service a request.

Figure 4-2. Classes in the HTTP Pipeline

The first thing that happens when a request is dispatched to an application is that an instance of the HttpWorkerRequest class is created (1), which contains all the information about the current request, including the requested URL, the headers, and so on. Once the HttpWorkerRequest class is created, it is passed into the static ProcessRequest method of the HttpRuntime class, which is executed in the AppDomain of the application, initiating the processing of the request (2). The first thing the HttpRuntime class does is to create a new instance of the HttpContext class, initialized with the HttpWorkerRequest class (3). The HttpContext class is the "glue" of the pipeline, since it holds all the classes together by keeping all the relevant information about the current request in one location. When the HttpContext class is first created, it allocates new instances of the HttpRequest and HttpResponse classes and stores them as fields. It also provides property accessors to the application and session state bags. Once the HttpContext class is created, the HttpRuntime class requests an instance of the HttpApplication -derived class for this application by calling the static GetApplicationInstance method of the HttpApplicationFactory class (4). GetApplicationInstance either creates a new instance of the HttpApplication (or a derivative) class or pulls one from a pool of application objects if one is available (5). Once the HttpApplication class is created or retrieved, it is initialized, and during its initialization it allocates any modules that are defined for this application (6). Modules are classes that implement the IHttpModule interface and serve to pre- and postprocess requests.

Once the modules have been created, the HttpRuntime class asks its newly retrieved HttpApplication class to service the current request by calling its BeginProcessRequest method (7), defined by the IHttpAsyncHandler interface implemented by the application class. The HttpApplication class then takes over the request processing and locates the appropriate handler factory for the current request, based on the URL path. For example, if the request is for an .aspx page, it uses the PageHandlerFactory class. Once it locates the appropriate factory, it invokes the GetHandler method on the IHttpHandlerFactory interface to retrieve a fresh copy of the appropriate handler class. Handler classes serve as the endpoint for requests and very often are simply the Page -derived class that is created from an .aspx file. In general, handlers are classes that implement the IHttpHandler interface and populate the response buffer when asked to process a request. Once the handler is created, its ProcessRequest method is called (8), passing in the current HttpContext class so that it has access to the Request , the Response , and all the other request-specific pieces of information necessary. Once the ProcessRequest method returns, the request is complete.