• Choose a category
• All
• Classic-Fiction

PostAcquireRequestState The state information (such as Application or Session) has been acquired. The state information is stored in the HttpContext’s related properties at this time.

PreRequestHandlerExecute This event is fired immediately prior to executing the handler for a given request.

ExecuteRequestHandler At this point, the handler does its job and generates the output for the client.

PostRequestHandlerExecute When this event fires, the selected HTTP handler has completed and generated the response text.

ReleaseRequestState This event is raised when the handler releases its state information and prepares to shut down. This event is used by the session state module to update the dirty session state if necessary.

PostReleaseRequestState The state, as modified by the page execution, has been persisted.

UpdateRequestCache The runtime environment determines whether the generated output, now also properly filtered by registered modules, should be cached to be reused with upcoming identical requests.

PostUpdateRequestCache The page has been saved to the output cache if it was configured to do so.

LogRequest The event indicates that the runtime is ready to log the results of the request. Logging is guaranteed to execute even if errors occur.

PostLogRequest The request has been logged.

EndRequest This event fires as the final step of the pipeline. At this point, the response is known and made available to other modules that might add compression or encryption, or perform any other manipulation.

Another pair of events can occur during the request, but in a nondeterministic order. They are PreSendRequestHeaders and PreSendRequestContent. The PreSendRequestHeaders event informs the HttpApplication object in charge of the request that HTTP headers are about to be sent. The PreSendRequestContent event tells the HttpApplication object in charge of the request that the response body is about to be sent. Both these events normally fire after EndRequest, but not always. For example, if buffering is turned off, the event gets fired as soon as some content is going to be sent to the client.

Speaking of nondeterministic application events, it must be said that a third nondeterministic event is, of course, Error.

Let’s delve deeper into the mechanics of ASP.NET request processing.

Note

Technically, most of the IIS pipeline events are exposed as events of the ASP.NET HttpApplication class. A significant exception is ExecuteRequestHandler. You find this event in the IIS messaging pipeline, but you won’t find an easy way to subscribe to it from within ASP.NET code. Internally, the ASP.NET runtime subscribes to this event to receive notification of when an ASP.NET request needs to produce its output. This happens when using unmanaged code that is not publicly available to developers. If you want to control how an incoming request is executed by IIS, you have to resort to Win32 ISAPI filters. If you want to control how an ASP.NET request is executed, you don’t need the IIS ExecuteRequestHandler event, because a simpler HTTP handler will do the job.

ASP.NET Request Processing in Integrated Pipeline Mode

In an integrated pipeline, an ASP.NET request is like any other request except that, at some point, it yields to a sort of simplified ASP.NET runtime environment that now just prepares the HTTP context, maps the HTTP handler, and generates the response.

When the application pool that contains an ASP.NET application running in Integrated Pipeline mode is initialized, it hosts ASP.NET in the worker process and gives ASP.NET a chance to register a set of built-in HTTP modules and handlers for the IIS pipeline events. This guarantees, for example, that Forms authentication, session state, and output caching work as expected in ASP.NET. At the same time, the ASP.NET runtime also subscribes to receive notification of when an ASP.NET request needs processing.

In between the PreRequestHandlerExecute and PostRequestHandlerExecute