Programming Microsoft ASP.NET 4 - Dino Esposito [82]
The Modules property is of type HttpModuleCollection and contains the names of the modules for the application. The collection class inherits from the abstract class NameObjectCollectionBase, which is a collection of pairs made of a string and an object. The string indicates the public name of the module; the object is the actual instance of the module. To access the module that handles the session state, you need code like this:
var sessionModule = app.Modules["Session"];
sessionModule.Start += OnSessionStart;
As mentioned, you can also handle events raised by HTTP modules within the global.asax file and use the ModuleName_EventName convention to name the event handlers. The name of the module is just one of the settings you need to define when registering an HTTP module.
Examining a Real-World HTTP Module
The previous example gave us the gist of an HTTP module component. It was a simple (and kind of pointless) example, but it was useful to demonstrate what you can do with HTTP modules in a real application. First and foremost, not all applications need custom HTTP modules. ASP.NET comes with a bunch of built-in modules, which are listed in Table 4-8.
Table 4-8. Native HTTP Modules
Event
Description
AnonymousIdentificationModule
Manages anonymous identifiers for the ASP.NET application
DefaultAuthenticationModule
Ensures that the User object is always bound to some identity
FileAuthorizationModule
Verifies that the user has permission to access the given file.
FormsAuthenticationModule
Manages Forms authentication
OutputCacheModule
Implements output page caching
ProfileModule
Implements the data retrieval for profile data
RoleManagerModule
Manages the retrieval of role information
ScriptModule
Manages script requests placed through ASP.NET AJAX
SessionStateModule
Manages session state
UrlAuthorizationModule
Verifies that the user has permission to access the given URL
UrlRoutingModule
Implements URL routing
WindowsAuthenticationModule
Manages Windows authentication
All these HTTP modules perform a particular system-level operation and can be customized by application-specific code. Because an HTTP module works on any incoming request, it usually doesn’t perform application-specific tasks. From an application perspective, an HTTP module is helpful when you need to apply filters on all requests for profiling, debugging, or functional reasons.
Let’s dissect one of the system-provided HTTP modules, which will also slowly move us toward the next topic of this chapter. Enter the URL-routing HTTP module.
The UrlRoutingModule Class
In ASP.NET 3.5 Service Pack 1, Microsoft introduced a new and more effective API for URL rewriting. Because of its capabilities, the new API got a better name—URL routing. URL routing is built on top of the URL rewriting API, but it offers a richer and higher level programming model. (I’ll get to URL rewriting and URL routing in a moment.)
The URL routing engine is a system-provided HTTP module that wires up the PostResolveRequestCache event. In a nutshell, the HTTP module matches the requested URL to one of the user-defined rewriting rules (known as routes) and finds the HTTP handler that is due to serve that route. If any HTTP handler is found, it becomes the actual handler for the current request. Here’s the signature of the module class:
public class UrlRoutingModule : IHttpModule
{
public virtual void PostResolveRequestCache(HttpContextBase context)
{
...
}
void IHttpModule.Dispose()
{
...
}
void IHttpModule.Init(HttpApplication application)
{
...
}
}
The class implements the IHttpModule interface implicitly, and in its initialization phase it registers a handler for the system’s PostResolveRequestCache event.
The PostResolveRequestCache Event
The PostResolveRequestCache event fires right after the runtime environment (IIS or ASP.NET, depending on the IIS working mode) has determined whether the response for the current request can be