HttpApplication Events, the HttpModules that Handle them and in What Order
It is a generally held opinion that to depend upon the order of module/event execution is bad practice and produces brittle code. I agree somewhat with the spirit of the opinion but not at all with the explicit reason.
Events and Collections are not magic bags that arbitrarily insert handlers/items in some random order. I think, in a general sense, that to depend on event handler execution order is a 'bad idea' is valid. In a more specific context, in which the environment is known and tightly controlled, the argument loses a bit of weight.
It is evident from reading the source for the built-in modules compared to the order that they are added to the collection that the calling order of initialization and application event handlers in registered
HttpModules is entirely dependant on the order in which they are added to the
There are, as illustrated below, sequential interdependencies in the execution logic of the built-in modules.
I believe that, in order to write custom modules that are affected by or intend to affect the execution of built-in modules, you must understand and may depend on the order of execution of the built-in modules and event handlers.
The primary argument against this is that the possibility of configuration change renders your sequentially dependant code brittle. I find that argument specious (yes, I am talking to you Rick. ;-))
If someone finds the need to go into the root web config file and fundamentally alter the behaviour of the ASP.NET runtime in a way that leaves an aftermarket module incompatible or faulty, how does that indicate brittle code in the module?
It smells like a simple requirements/compatibility issue to me. How the module author states requirements and handles the absence of those requirements is another issue entirely.
Listings follow that are the result of a reflector dive and reflection wrapper binge I did in the interest of improving the behavior of
FormsAuthentication in regards to non-authenticated versus underpriveleged access to a resource.
Any corrections or improvements are completely welcome.
Listing 1: Default httpModules sections
<add name="OutputCache" type="System.Web.Caching.OutputCacheModule"/>
<add name="Session" type="System.Web.SessionState.SessionStateModule"/>
<add name="RoleManager" type="System.Web.Security.RoleManagerModule"/>
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"/>
<add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule"/>
<add name="Profile" type="System.Web.Profile.ProfileModule"/>
Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add name="ServiceModel" type="System.ServiceModel.Activation.HttpModule,
System.ServiceModel, Version=22.214.171.124, Culture=neutral,
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=126.96.36.199, Culture=neutral,
Event handlers described below are executed only if the module/mode is enabled/valid. The sequential interdependencies are self evident.
Descriptions are not meant to be authoritative, only generally descriptive.
A full explanation of the application lifecycle can be found @ http://msdn.microsoft.com/en-us/library/ms178473.aspx and Reflector can be found @ http://www.red-gate.com/products/reflector/.
Listing 2: Sequenced Pipeline Events
- Uses thread identity and sets User on Context
- Uses forms ticket and sets User on Context
- Similar to forms but not worth the effort to examine in further detail
Context.SkipAuthorization = true If application is
null (?), the request is for a script resource or request is for
- Discovers roles from cookie or Roles and replaces
Context.User Principal with a
- Manages an anonymous identifier for unauthenticated requests/sessions
- Seems to be an internal wrapper/placeholder for services. Usage is not clear to me at this time.
false checks permissions and sets 401 if fail. Faulty logic. Should be replaced with more discriminative code that differentiates a 401 from a 403.
- checks ntfs permissions and sets 401 if fail.
- Checks cache policy against request to determine whether to serve cached content.
- Hydrates session
- Sets Profile on Context
- Executes '
- Removes session from context
- Checks cache policy against response to determine whether to cache content.
- Updates session items timeout.
- If request status 401 and not on login page (via very ugly kludge) redirects to login page.
- Similar to forms but not worth the effort to examine in further detail.
- Updates role cookie if
RolePrinicipal roles have changed since
- Updates Profile store from Context if
AsyncPostBackError, clears response and writes out text/plain error message
System.Web.Handlers.ScriptModule- Handles 302 (redirects). For
AsyncPostBackRequests the cookies are transferred to a new text/plain redirect message and for
RestRequests ('application/json') a 401 is set with json text content.
Understanding the application pipeline and request lifecycle will demystify a great deal of what happens and why in between the time a URL is entered and content is served. It can also make you more effective at writing code that capably influences the request lifecycle.
It is not black magic nor is it insanely complex or undiscoverable. Get a copy of Reflector and find out for yourself.