Using an HttpHandler to Forward Requests to a New Domain

One of the hardships of moving to a new domain is intercepting and forwarding traffic from the old domain name over to the new one (without losing any traffic/google ranking/etc).  Custom HttpHandlers in .Net make this scenario ridiculously easy to overcome.  Pre-.Net, you would have had to roll your own ISAPI filter (in C++ no less) to accomplish something this seemingly trivial (though there is probably lots of pre-rolled code floating around out there, and more than likely some pre-baked turnkey 3rd party solutions as well).  Anyone who’s worked with custom ISAPI stuff knows that it has a habit of making trivial stuff not so trivial anymore…it’s a total PITA.

Enter the IHttpHandler interface, which in my opinion makes ASP.NET one of the most powerful web frameworks out there in how easy it allows developers to write their own IIS Http Handlers.  I’ve utilized it quite a bit in my development forrays, and it hasn’t failed me yet.  In this specific case (migrating from zerotrilogy.gotdns.com over to jaysonknight.com), the raw URL (the stuff after the domain) itself stayed the same (as it should), just needed to swap out the domain name for incoming requests and redirect to the new domain.  So, here’s what needs to be done:

• Write a class that derives from IHttpHandler.
• Intercept all requests (i.e. map all incoming requests to the HttpHandler written above).
• Parse the URL, swapping out the domain name.
• Redirect the requests to the rewritten URL.

Here’s the code for the Redirect class (very much simplified…the URL's should actually be stored in a configuration file, but just keeping it simple here):

 using System;
 using System.Web; 
 namespace Dottext.Web
 {
       ///
       /// Summary description for Redirect.
       ///
       public class Redirect : IHttpHandler
       {
             public Redirect() {}
  
             #region IHttpHandler Members
  
             public void ProcessRequest(HttpContext context)
             {
                   string newURL, oldURL;
                   string oldURLLocal = "localhost/jaysonblog";
                   string oldURLRemote = "zerotrilogy.gotdns.com/jaysonblog";
                   string newURLRemote = "jaysonknight.com/blog";
                   oldURL = context.Request.Url.ToString().ToLower();
                   if (oldURL.StartsWith("http://localhost"))
                   {
                         newURL = oldURL.Replace(oldURLLocal, newURLRemote);
                   }
                   else
                   {
                         newURL = oldURL.Replace(oldURLRemote, newURLRemote);
                   }
            context.Response.AddHeader("Location", newURL);
            context.Response.StatusCode = 301;
            context.Response.End();
             }
  
             public bool IsReusable
             {
                   get
                   {
                         return true;
                   }
             }
  
             #endregion
       }
 }
 

In essence, you have complete control over the HttpContext and can pretty much do anything you want with it.  It’s really obscenely simple.  All that’s left to do is map all incoming requests to the Redirect class in the web.config file (we’re redirecting all requests in this case, though you can map whatever content you need (.aspx, .asmx, etc)):

 <httpHandlers>
     <add verb="*" path="*" type="Dottext.Web.Redirect, DotText.Web" />
 < /httpHandlers>

The great thing about this type of solution is that it doesn’t matter where the user is coming in from…you can intercept it all and handle accordingly, this basically just serves as a broker of sorts.  The biggest caveat is that Response.Redirect will generate a ThreadAbort exception do to an intrinsic calling of Response.End.  The end user won’t see the exception, but it causes the CLR to have to work overtime in handling the exception under the hood and will degrade performance, so make sure the application is in a different application pool in IIS (6.0 of course…and if you’re not running 6.0, application pools are a very compelling reason to migrate…but that’s another post).  Happy redirecting.