Programming Microsoft ASP.NET 4 - Dino Esposito [18]
Note that in IIS 7, the unified architecture is optional and can be disabled through the IIS Manager tool, as shown in Figure 2-4. The Integrated Pipeline mode, however, is the default working mode for new application pools. In the rest of the chapter, I’ll assume application pools are configured in Integrated Pipeline mode unless otherwise specified.
Figure 2-4. Configuring the application pool Integrated Pipeline mode in IIS 7.
The Journey of an HTTP Request in IIS
To make sense of the IIS architecture, let’s go through the steps of the typical journey of HTTP requests that hit an ASP.NET application.
Any HTTP request that knocks at the IIS door is queued to the application pool that the target application belongs to. The worker process picks up the request and forwards it to the application. The details of what happens next depend on the IIS 7 pipeline mode—Classic or Integrated Pipeline. (IIS 7 configured to work in Classic mode behaves according to the model of its predecessor, IIS 6.)
In IIS 7.0 running in Integrated Pipeline mode, no explicit handoff of the request from IIS to ASP.NET ever occurs. The runtime environment is unified and each request goes through only one chain of events.
Events in the Request Life Cycle
The following list of events is fired within the IIS messaging pipeline. Handlers for these events can be written through managed code both in the form of HTTP modules (as discussed in Chapter 4,) and code snippets in global.asax. Events are fired in the following sequence:
BeginRequest The ASP.NET HTTP pipeline begins to work on the request. For the first request ever in the lifetime of the application instance, this event reaches the application after Application_Start.
AuthenticateRequest The request is being authenticated. ASP.NET and IIS integrated authentication modules subscribe to this event and attempt to produce an identity. If no authentication module produced an authenticated user, an internal default authentication module is invoked to produce an identity for the unauthenticated user. This is done for the sake of consistency so that code doesn’t need to worry about null identities.
PostAuthenticateRequest The request has been authenticated. All the information available is stored in the HttpContext’s User property at this time.
AuthorizeRequest The request authorization is about to occur. This event is commonly handled by application code to perform custom authorization based on business logic or other application requirements.
PostAuthorizeRequest The request has been authorized.
ResolveRequestCache The runtime environment verifies whether returning a previously cached page can resolve the request. If a valid cached representation is found, the request is served from the cache and the request is short-circuited, calling only any registered EndRequest handlers. ASP.NET Output Cache and the new IIS 7.0 Output Cache both feature “execute now” capabilities.
PostResolveRequestCache The request can’t be served from the cache, and the procedure continues. An HTTP handler corresponding to the requested URL is created at this point. If the requested resource is an .aspx page, an instance of a page class is created.
MapRequestHandler The event is fired to determine the request handler.
PostMapRequestHandler The event fires when the HTTP handler corresponding to the requested URL has been successfully created.
AcquireRequestState The module that hooks up this event is willing to retrieve any state information for the request. A number of factors are relevant here: the handler must support session state