In my recent quest to integrate support for SiteMinder into the ASP.NET Membership process I found myself looking into the details of ASP.NET Http Modules. Once of the areas that I spent time on was understanding the exact order of events in the life cycle of a module. Here is what I found.
The HttpApplication is usually un-heard of and it works quietly behind the scenes – well not really. If you have written a HttpHandler or HttpModule or any application with some sort of complexity before – you probably already know what its all about. The HttpApplication is the base class for all ASP.NET application objects, therefore, an HttpApplication class is created for each request. However, not to get too deep into the world of the HttpApplication, I want to focus this post on the sequence of events that are executed – its pipeline.
Any HTTP module that subscribes to an HttpApplication event must implement the IHttpModule interface, also if you look at the list you will notice that each event has a corresponding post event. i.e AuthenticateRequest to PostAuthenticateRequest. These posts events are executed after its parent event has completed, therefore, PostAuthenticateRequest is raised after the AuthenticateRequest.
This is the very first event that is raised when ASP.NET responds to a request and it is always raised. Listen to this event for new requests.
As the name implies, this event fires on authentication of the user. Therefore, if you would like to know who is accessing your site, the “Post” of this event would be ideal to set a listener. It simply states that the request has been authenticated or the identity of the user has been established.
Authorizing the request is the next step right after the request has been authenticated. Trap “Post” of this event to determine if the user is authorized to access the particular resource or not.
Ok, it gets tricky. This event occurs after the authorize event and data is requested from cache. If the cache exist, the event handler such as a page will be bypassed and the cached request will be served. You can do several things here. Blow your mind!
A post event with no “Pre” – at least no access to it. This event get raised after the request has been mapped to a handler. So if you would like to know which handler will be executed, this is the place to be.
This executes right after the handler has been mapped to the request and it grabs the current state such as session state. Trap the “Post” event if you need to mess around with the session.
As the name implies, this event is raised just before the request handler that was mapped earlier on is executed such as a “.aspx” or “.asmx” page.
At this point in time all mapped handlers have been executed and state modules will start saving state data as required.
Completely opposite off the above, this event is raised to signal caching modules to save response data which may be used in future request during the ResolveRequestCache phase.
It has to end somewhere. The EndRequest is the last event raised.
I hope this post has helped you understand how the HttpApplication pipeline flows and also help you understand which events to trap to enable you to perform some tasks at the right time.