Wednesday, May 23, 2007
There is a discussion over at Scott Hanselman's site about URL Rewriting in ASP.NET.  I found a similar article about URL Rewriting in ASP.NET on Coding Horror


Synopsis:

Here is a brief synopsis of the problem.  In order to have an http module or handler take care of your url rewriting you must have all requests sent to aspnet_isapi.dll via application extension mapping in IIS 6.

Here is an example:

I want http://whatyour20.com/modules/view-location.aspx?locid=1234

to instead look like:

http://whatyour20.com/locations/yellowstone-national-park/

I do this for several reasons.  The number one reason is SEO.  We want google to give google a good idea of what this page is about.  Obviously the latter url does the much better.  It also gives the users an idea of what the link is about.  Number two, it makes our links hackable.  Number 3, it makes our links more aesthetically pleasing.  I think that is very important.  If I see a url that is meant for people instead of machines, I know the web site creator took some time to dot every i and cross every t.  Number four is the less likely option that I will switch technologies and I don't want to lose all my links and there associated page rank if I switch to a new technology or if Microsoft changes thier extension in the future when the next great thing comes out (Silverlight Foundation Server Pages Advanced with SteelRuby, LOL). 

At whatsyour20.com we use UrlRewritingNet.UrlRewrite to handle all url rewriting duties.  UrlRewrite is an asp.net http module that can rewrite any incoming url and it can handle redirects (301, 302).  This works great but it doesn't get rid of the aspx extension by itself.  In fact no http module or handler can do that because iis uses the file extension to determine which program should handle the request. 

So we need to have IIS route all requests for the domain (http://whatsyour20.com) to the aspnet_isapi.dll as stated above.  The problem with this is that now ALL request will go through asp.net.  We may not need this for all requests.  In fact this can be a problem as it can hurt performance.  I've seen the a claim of 30% performance decrease someplace but I don't remember where right now.  However, it's safe to assume that routing static content through asp.net is just not the best solution.

Solution:

The solution?  After the background information we are finally at the payoff.  This is how we get the goodness of using asp.net url rewriting via http modules and the associated debugging and high level of control this brings us WITHOUT the downside of routing static content through asp.net. 

We access all the static content via a sub-domain.  We use static.whatsyour20.com to server all the static content on the site (Right now this is mostly images).  This is very easy to accomplish.  You simply create another web site in IIS, with the path to the same location as your main domain but using the sub domain.  On this domain you DO NOT route the requests to asp.net.  So on this sub domain all content is handled by IIS because it is static.  You could even take that a step farther and put it on a separate server or use another web server that is optimized for static content. 

Our solution works in a share hosting environment because usually you can set up sub domains on shared hosting.  Also you can usually get all requests routed to asp.net if you put in a ticket and simply ask for it.

A nice side effect of using sub domains is improved performance on the client side.  By increasing the number of hostnames (within reason) we can increase the speed at which the page loads.

Here are a few reference articles on multiple domains names to speed up downloads:
http://yuiblog.com/blog/2007/04/11/performance-research-part-4/
http://www.ajaxperformance.com/?p=33
http://www.die.net/musings/page_load_time/

Conclusion:

Using the presented solution we get a urlrewriting solution that is easy to use and configure (all configuration in web.config), transfers easily between hosting providers (again its all provided by asp.net and web.config) and it improves performance.  I'm still looking for any possible downsides.  Please let me know if you know of any.


Wednesday, May 23, 2007 7:29:14 PM (Central Standard Time, UTC-06:00)  #    Comments [1]