In a web application, it’s often necessary to redirect clients requesting one url to another url. Here are some reasons why your application may need to do it:
· A part of your site should only be accessed over HTTPS to protect private data, so you want to redirect requests made over HTTP to same urls with HTTPS.
· You want to make sure that everyone accesses your blog as domain.com, and not www.domain.com for better search engine rankings.
· The structure of your application changed – your product pages used to be in the “/catalog” subdirectory but now they are in the “/products” subdirectory.
In these and many more cases, you will need to redirect clients making requests to some urls in your site that match a particular rule to other urls. In general, there are server different ways that you can do redirection on a web server:
1. Http Redirection. The web server tells the client that the content the client is looking for is located at a different address, and the client automatically (most of the time) requests the redirected address.
2. Server-side rewriting. The web server changes the url being requested internally, so that the new resource is processed and returned in response to the original url, without telling the client.
The main difference being that with redirection, the client is aware of the change in url and makes a separate request to the new url, and with rewriting the client is oblivious to the change.
This makes redirection more suitable for when you want the client to see the new url, and possibly remember/bookmark it. Redirection is also the only option whenever the redirected url does not reside in your site or even on your server (there is a third option, called forwarding / proxying, that allows rewrites to other servers to be done internally – more on that in a later post).
Server-side rewriting is better if the rewrite is for internal purposes only – for example, you expose SEF (search engine friendly) urls to your clients, but internally you need to rewrite to an ASP.NET or PHP script to provide the processing for the request. Server-side rewriting is often also faster because there is no need to tell the client about the rewrite, and then have the client make a second request. Rewriting can also be trickier on the server, because it’s a lot more sensitive to when the rewrite is made during the processing of the request. If it’s not made at the right time, certain processing stages have already took place for the old url, and you may see undesired results.
Doing redirection with the HttpRedirection module
A while ago, I wrote a module to do basic http redirection for an ASP.NET application. The HttpRedirection module allows you to configure regular expression-based rules that redirect clients from url A to url B using http redirection. You can also inject useful variables into the match and redirection url expressions, control the type of redirects that are performed (temporary vs. permanent), and in what stage of request processing they are performed.
Here are some examples of the things you can do:
<!– Redirect all HTTP requests to application to HTTPS –>
<!– Redirect to a localized version of the app –>
<!– Redirect to the same url, placing the Referer http header in the querystring –>
I was looking for an image that I could use for this post, and found this (apparently my LeechGuard module is not being used to prevent hot-linking on that website :)) and found this – I think it says it all:
The module is supported both for legacy ASP.NET applications on IIS5+, but can also be used to do redirection for all resource types using IIS6 / ASP.NET 2.0 wildcard mapping support, or the IIS7 integrated pipeline.
That’s it. Let me know if you are using it, and if you have any questions / suggestions / complaints by leaving comments. I’ll be covering server-side rewriting and its complexities in a future post.