Programming Microsoft ASP.NET 4 - Dino Esposito [20]
This ASP.NET internal handler is called back by IIS whenever an ASP.NET request needs to be processed. The handler invokes a new static method on the HttpRuntime object that kicks in to take care of the request notification. The method retrieves the HTTP handler in charge of the request, prepares the HTTP context for the request, and invokes the HTTP handler’s public interface. Figure 2-5 offers a graphical view of the steps involved.
Figure 2-5. How the IIS 7 integrated pipeline processes an ASP.NET request.
Building a Response for the Request
Each ASP.NET request is mapped to a special component known as the HTTP handler. The ASP.NET runtime uses a built-in algorithm to figure out the HTTP handler in charge of a given ASP.NET request.
In Web Forms, this algorithm is based on the URL of the requested page. You have a different HTTP handler for each page requested. If you requested, say, page.aspx, the HTTP handler is a class named ASP.page_aspx that inherits from the code-behind class you specified in your source code. The first time the request is made this class doesn’t exist in the AppDomain. If the class does not exist, the source code for the class is obtained by parsing the ASPX markup and then it’s compiled in memory and loaded directly into the AppDomain. Successive requests then can be served by the existing instance.
An HTTP handler is a managed class that implements the IHttpHandler interface, as shown in the following code snippet. The body of the ProcessRequest method ultimately determines the response for the request.
public interface IHttpHandler
{
void ProcessRequest(HttpContext context);
bool IsReusable { get; }
}
The base class for Web Forms pages—the System.Web.UI.Page class—is simply a class that provides an extremely sophisticated implementation of the IHttpHandler interface, which basically turns out to be a full implementation of the Page Controller pattern. The ProcessRequest method of the System.Web.UI.Page class consumes posted data, view state, and server controls to produce the resulting HTML for the client. Needless to say, the Page class assumes that your request is for an HTML page as described by the content available in a server ASPX file.
For individual requests, or for a logically defined group of requests, within an application you can define an alternate handler class that employs different logic to generate the response. This alternate HTTP handler can be mapped to a particular URL, and it doesn’t have to point necessarily to an existing server resource. Ultimately, this is just what ASP.NET MVC does.
Note
As you’ll see in Chapter 4, ASP.NET Web Forms supports URL routing, which essentially allows you to map an incoming URL to a specific ASPX page. The standard algorithm for mapping URLs to HTTP handler classes as described here only works if you’re not using Web Forms URL routing.
Adding Your Own Code to the Pipeline
As mentioned, you can write your own handlers for many of the request life-cycle events listed earlier in the chapter. You can do that by writing a managed HTTP module or by adding code to the global.asax file of your ASP.NET application. Let’s briefly consider what it takes to extend the global.asax file. Here’s a piece of code that shows what you end up with:
protected void Application_PostAuthenticateRequest()
{
// Your code here
}
You use the Application_Xxx notation to define a handler for the Xxx event fired at the application level. For example, the code snippet gives you a chance to run some custom code