In a previous post, I talked about HttpHandlers – an underused but incredibly useful feature of ASP.NET. Today I want to talk about HttpModules, which are probably more common than HttpHandlers, but could still stand to be advertised a bit more.

HttpModules are incredibly easy to explain, so this will hopefully be a short-ish post. Simply put, HttpModules are portable versions of the global.asax. So, in your HttpModule you’ll see things like BeginRequest, OnError, AuthenticateRequest, etc. Actually, since HttpModules implement IHttpModule, you actually only get Init (and Dispose if you have any cleanup to do). The Init method passes in the HttpApplication which lets you hook into all of those events. For example, I have an ErrorModule that I use on most projects:

using System;
using System.Web;
using log4net;

namespace Fuel.Web
{
 public class ErrorModule : IHttpModule
 {
  #region IHttpModule Members
  public void Init(HttpApplication application)
  {
   application.Error += new EventHandler(application_Error);  
  }      
  public void Dispose() { }
  #endregion

  public void application_Error(object sender, EventArgs e)
  {
    //handle error
  }
 }
}

Now, the code in my error handler is pretty simple:

HttpContext ctx = HttpContext.Current;
//get the inner most exception
Exception exception;
for (exception = ctx.Server.GetLastError(); exception.InnerException != null; exception = exception.InnerException) { }
if (exception is HttpException && ((HttpException)exception).GetHttpCode() == 404)
{
 logger.Warn(“A 404 occurred”, exception);
}
else
{
 logger.Error(“ErrorModule caught an unhandled exception”, exception);
}

I’m just using a log4net logger to log the exception, if it’s a 404 I’m just logging it as a warning.

You can do this just as easily with a global.asax, but those things aren’t reusable across projects. That of course means that you’ll end up duplicating your code and making it hard to manage. With my ErrorModule class, I just put it in a DLL, drop it in my bin folder and add a couple lines to my web.config under <system.web>:

<httpModules>
 <add  name=”ErrorModule” type=”Fuel.Web.ErrorModule, Fuel.Web” />
</httpModules>

And voila, I have a global error in place.

In almost all cases, you should go with HttpModules over global.asax because they are simply more reusable. As another example, my localization stuff uses an HttpModule as the basis for adding a multilingual framework to any application. Simply drop the DLL in the bin and add the relevant line in your web.config and you’re on your way. Here’s the important code from that module:

public void Init(HttpApplication context)
{
 context.BeginRequest += new EventHandler(context_BeginRequest);
}
public void Dispose() {}
private void context_BeginRequest(object sender, EventArgs e)
{
 HttpRequest request = ((HttpApplication) sender).Request;
 HttpContext context = ((HttpApplication)sender).Context;
 string applicationPath = request.ApplicationPath;
 if(applicationPath == “/”)
 {
    applicationPath = string.Empty;
 }
 string requestPath = request.Url.AbsolutePath.Substring(applicationPath.Length);
 //just a function that parses the path for a culture and sets the CurrentCulture and CurrentUICulture
 LoadCulture(ref requestPath);
 context.RewritePath(applicationPath + requestPath);
}

If you are developing a shrink-wrap product, you don’t have a choice but to use HttpModules, because the last thing you want is to ship a global.asax which the user must use, overwriting the code in his own global.asax.

The only time you want to use Global.asax is when using OutputCaching with the VaryByCustom property. As far as I know, the GetVaryByCustomString function _must_ be placed in the global.asax file.

Anyways, switching from Global.asax to HttpModules is pretty straightforward. So I encourage you to look at where it makes sense (ie, where you see the potential for reuse across applications) and make it so.