how IIS and ASP.NET communicate

 January 13, 2004 http://www.theserverside.net/tt/articles/showarticle.tss?id=IIS_ASP 
Get the code here! 
IntroductionTools like ASP.NET greatly simplify the development of a complex Web application. Although this is a great thing for general productivity, it can also keep you from understanding the fundamental communications between your Web server and your ASP.NET application code. Furthermore, there will be times when you need to butt-in and intercept HTTP requests, which requires a greater understanding of the process of communication between your Web server of choice, and ASP.NET. 
This article explains how IIS and ASP.NET communicate, and describes some techniques for intercepting some of this communication. I’ll review how ASP.NET is configured to handle requests, and how applications and Web services are handled by default. 
Then I’ll discuss how you might butt-in to those requests with HTTP handlers, handler factories and modules. You’ll see how they function individually and together through a series of examples. 
 
From IIS to ASP.NETIIS communicates with the .NET framework through unmanaged ISAPI extensions: aspnet_isapi.dll and aspnet_filter.dll. The aspnet_isapi.dll is an extension that serves as a request router, and the aspnet_filter.dll is a filter that primarily handles cookieless session states for ASP.NET. These unmanaged components, along with the state Windows service (aspnet_state.exe) and the ASP.NET worker process (aspnet_wp.exe) are the core of the ASP.NET processing model. 
When the .NET framework is installed on a machine that has IIS installed, IIS is configured so that requests for specific extensions are handled by aspnet_isapi.dll. As a point of interest, the filter is also configured within IIS.. 
 
Requests for ASP.NET resources are forwarded by IIS to ASP.NET via this configured extension. This extension is the bridge between unmanaged and managed code. Before control is passed to your application, an ASP.NET application object must be instantiated (by the runtime) and configuration settings are considered to determine how this request should be handled. Machine.config and collective web.config files are processed collectively to support this process. 
 
For this article, we are specifically interested in the <httpHandlers> configuration section. Settings in this section indicate which .NET type should handle the request. The default settings found in the machine.config file when .NET is installed, are as follows: 
<httpHandlers> 
   <add verb="*" path="trace.axd" type="System.Web.Handlers.TraceHandler"/> 
   <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/> 
   <add verb="*" path="*.ashx" type="System.Web.UI.SimpleHandlerFactory"/> 
   <add verb="*" path="*.asmx" type="System.Web.Services.Protocols.WebServiceHandlerFactory, 
System.Web.Services, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/> 
   <add verb="*" path="*.rem" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, 
System.Runtime.Remoting, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/> 
   <add verb="*" path="*.soap" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, 
System.Runtime.Remoting, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/> 
   <add verb="*" path="*.asax" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.ascx" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.cs" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.csproj" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.vb" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.webinfo" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.asp" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.licx" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.resx" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="*" path="*.resources" type="System.Web.HttpForbiddenHandler"/> 
   <add verb="GET,HEAD" path="*" type="System.Web.StaticFileHandler"/> 
   <add verb="*" path="*" type="System.Web.HttpMethodNotAllowedHandler"/> 
</httpHandlers> 

The <httpHandlers> section indicates which HTTP handler factory, or handler, should be used to handle the request. In summary, the high-level workflow from IIS to your ASP.NET applications is as follows: ?IIS receives request for a resource 
?For resources mapped to ASP.NET ISAPI Extension (i.e., *.aspx, *.asmx) the request is passed to an unmanaged ASP.NET DLL which communicates with the HttpRuntime object 
?The HttpRuntime object handles creation of the HttpApplication object (as needed), and the inspection of configuration settings, then passes control to the appropriate handler for the request 
?The handler is created to process request, which ultimately sends a response 
The following diagram illustrates this workflow: 
 
<httpHandlers> settings can be modified at the global (machine.config) level, or overridden at the application (web.config) level. In other words, you can specify a different factory or handler to process particular resource requests. For example, to reject requests for *.rem objects, you can edit the machine.config, or the application web.config as follows: 
<add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/ 
Associating the HttpForbiddenHandler with *.rem replaces the default behavior, which be to use HttpRemotingHandlerFactory. If you specify this override in the machine.config, this will impact all applications on the Web server. 
 
HTTP Handlers and Handler FactoriesAs mentioned above, the ASP.NET runtime relies on HTTP handlers or handler factories to process requests. Configuration file settings associate an HTTP handler or handler factory class with specific resources. Let’s take a closer look at these settings. 
The following entry associates the System.Web.UI.PageHandlerFactory class with *.aspx resources, for all HTTP verbs (i.e., GET, POST): 
<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/> 
This next entry associates System.Web.HttpForbiddenHandler with *.config resources: 
<add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler"/> 
These are preexisting classes provided with the base class library, but you can also build custom handlers and handler factories, by implementing the IHttpHandlerFactory and IHttpHandler interface (respectively). Before we talk about how to implement custom handlers and factories, let’s review their features. From a high level, HTTP handler factories are specified in order to dynamically return the correct HTTP handler object to manage the requested resource. If an HTTP handler is specified, it is instantiated directly by the runtime. Regardless, the end-result is to invoke a handler for the resource. 
After the runtime passes control to a handler, it is the handler’s job to handle the request, instantiating the appropriate ASP.NET server-side objects, and send an HTTP response. For example, PageHandlerFactory returns a System.Web.UI.Page object for the requested *.aspx resource, and System.Web.HttpForbiddenHandler throws an HttpException indicating that the request is not supported. 
Implementing IHttpHandlerSimilar to ISAPI extensions, handlers provide low-level access to HTTP request and response objects. Implementing a custom handler allows you to process specific resources differently. You can intercept requests for those resources and override the response. For example, if you wanted to log the IP addresses of those requesting forbidden files, you could write a handler that logged information about those requests before throwing an HttpException. You may even want to send back a little love note to those making such request, as shown in the sample code, like this: 
 
To create a custom HTTP handler, create a .NET component that implements IHttpHandler. This interface has the following members: 

• ProcessRequest() – this method is invoked by the runtime to handle the request 
• IsReusable – this property indicates if multiple requests can share the same handler 

ProcessRequest() is passed the HttpContext for the request, which can be used to access HttpRequest, HttpResponse and HttpSessionState objects. 
NOTE: A handler must implement IRequiresSessionState if it will access the session object. 
Here is a simple example of an HTTP handler that writes output to the browser: 
   public class ForbiddenLogHandler: IHttpHandler 
   { 
     public ForbiddenLogHandler() 
     { 
     } 

     public virtual void ProcessRequest(HttpContext context) 
     { 
         
        context.Trace.Write("ForbiddenLogHandler.ProcessRequest()"); 

        HttpResponse rs = context.Response; 
        HttpRequest rq = context.Request; 

        rs.Write("<p><H1>We know who you are...</H1></p>"); 

        rs.Write("You were referred by " + rq.UrlReferrer + "<br>"); 
        rs.Write("Your IP is" + rq.UserHostAddress + "<br>"); 
        rs.Write("Your domain is" + rq.UserHostName + "<br>"); 
        rs.Write("<p>Why were you requesting a restricted resource?</p>"); 

     } 
     
     public virtual bool IsReusable 
     { 
        get { return true; } 
     } 
   } 
The following web.config section configures the ForbiddenLogHandler for any *.cs, *.resx,&nbs ...