The Universal HttpHandlerFactory Technique

In the past two months I've done more with HttpHandlers than probably anything else. One technique that I'm finding myself use a lot is one that uses a universal HttpHandlerFactory to filter ALL ASP.NET 2.0 traffic. In fact, this is exactly what I'm doing in the next release of Minima. The next release actually has many HttpHandlers, each utilized by a master HttpHandlerFactory. Here's an example of what I'm doing and how you can do it too:

First, I create a wildcard mapping in IIS to:

c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll

When doing this you want to make sure to uncheck the "Verify that file exists" or else your pages will have to actually exist. For most of the HttpHandlers that I create, the pages that are being accessed are completely imaginary.

Next, I create my HttpHandlerFactory. The normal way of doing this is to create a class which implements the IHttpHandlerFactory, have your logic in the GetHandler method do whatever it must do, and then return an instance of a class implementing IHttpHandler. If I don't want to do anything fancy with the request, I can just process it as an ASPX page. Unfortunately, since we are going to run EVERYTHING in the website through the HttpHandlerFactory, we can't do that. Why? The HttpHandlerFactory that processes ASPX pages is PageHandlerFactory, which you can't return from our custom HttpHandlerFactory. Here's what I mean...

public IHttpHandler GetHandler(HttpContext context, String requestType, String url, String pathTranslated) {
    if (url.EndsWith("/feed/")) {
        return new FeedHttpHandler( );
    }
    else {
        return new PageHandlerFactory( );
    }
}

The preceding code in no way compiles. First off, PageHttpFactory implements IHttpHandlerFactory (well, IHttpHandlerFactory2, which in turn implements IHttpHandlerFactory), NOT IHttpHandler. Secondly, though completely irrelevant by the first reason, the single constructor for PageHttpFactory is marked as internal.

Fortunately, however, we can get around his by actually inheriting from PageHttpFactory and overriding the GetHandler, which is marked as virtual.

Here's an example that does compile and works beautifully:

namespace MyProject.Web.HttpExtensions
{
    public class MyProjectHttpHandlerFactory : PageHandlerFactory
    {
        public override IHttpHandler GetHandler(HttpContext context, string requestType, string virtualPath, string path) {
            if (context.Request.Url.AbsoluteUri.EndsWith("/feed/")) {
                return new FeedHttpHandler( );
            }
            if (context.Request.Url.AbsoluteUri.Contains("/files/")) {
                return new FileMapperHttpHandler( );
            }
            if (context.Request.Url.AbsoluteUri.Contains("/service/endpoint/")) {
                return new XmlServiceHttpHandler( );
            }
            if (context.Request.Url.AbsoluteUri.Contains("/images/")) {
                return new ImageProcessorHttpHandler( );
            }
            else {
                return base.GetHandler(context, requestType, virtualPath, path);
            }
        }
    }
}

To complete the solution, you simply have to add the following in your web.config file:

<httpHandlers>
  <add verb="*" path="*" type="MyProject.Web.HttpExtensions.MyProjectHttpHandlerFactory"/>
</httpHandlers>

Now we are filtering all content through our HttpHandler. By doing this, you have full control of what URLs mean and do without having to screw with a ton of strange HttpHandlers in your web.config file. Furthermore, by doing it this way you get better control of what your web.config looks like. In Minima, for example, I have a type which controls all access to various configurations. My primary HttpHandlerFactory looks at this type to determine what paths do what and go where. You can either use the defaults in Minima or you can override them in the web.config file.

Regardless of what you do, the point is you can do anything you want. I often find myself creating virtual endpoints for web services allowing access in a variety of ways. In one service I recently created I actually have parameters coming in in the form of a URL (http://MyWebsite/Endpoint/ABCCompany/). My HttpHandlerFactory notices that a certain handler is to handle that particular type of request and then returns an instance of that particular handler. The handler then obtains the parameters from the URL and processes the request appropriately. Very little work was done in the actual setup and almost no work was done in IIS, it's all magically done via the master HttpHandlerFactory.