Introduction
One of the most popular extensions to the Apache webserver has been mod_rewrite - a filter which rewrites URLs. For example, instead of a URL such as
Collapse
http://www.apache.org/BookDetails.pl?id=5
you could provide a filter which accepts URLs such as
Collapse
http://www.apache.org/Book/5.html
and it will silently perform a server-side redirect to the first URL. In this way, the real URL could be hidden, providing an obfuscated facade to the web page. The benefits are easier to remember URLs and increasing the difficulty of hacking a website.
Mod_rewrite became very popular and grew to encompass a couple of other features not related to URL Rewriting, such as caching. This article demonstrates URL Rewriting with ASP.NET, whereby the requested URL is matched based on a regular expression and the URL mappings are stored in the standard ASP.NET web.config configuration file. ASP.NET includes great caching facilities, so there's no need to duplicate mod_rewrite's caching functionality.
As more and more websites are being rewritten with ASP.NET, the old sites which had been indexed by google and linked from other sites are lost, inevitably culminating in the dreaded 404 error. I will show how legacy ASP sites can be upgraded to ASP.NET, while maintaining links from search engines.
ASP.NET support for URL Rewriting
ASP.NET provides very limited support out of the box. In fact, it's support is down to a single method:
Collapse
void HttpContext.RewritePath(string path)
which should be called during the Application_BeginRequest() event in the Global.asax file. This is fine as long as the number of URLs to rewrite is a small, finite, managable number. However most ASP sites are in some way dynamic, passing parameters in the Query String, so we require a much more configurable approach.
The storage location for all ASP.NET Configuration information is the web.config file, so we'd really like to specify the rewrites in there. Additionally, .Net has a fast regular expression processor, giving free and fast search and replace of URLs. Let's define a section in the web.config file which specifies those rewrites:
Collapse
<configuration>
<system.web>
<urlrewrites>
<rule>
<url>/urlrewriter/show\.asp</url>
<rewrite>show.aspx</rewrite>
</rule>
<rule>
<url>/urlrewriter/wohs\.asp</url>
<rewrite>show.aspx</rewrite>
</rule>
<rule>
<url>/urlrewriter/show(.*)\.asp</url>
<rewrite>show.aspx?$1</rewrite>
</rule>
<rule>
<url>/urlrewriter/(.*)show\.html</url>
<rewrite>show.aspx?id=$1&cat=2</rewrite>
</rule>
<rule>
<url>/urlrewriter/s/h/o/w/(.*)\.html</url>
<rewrite>/urlrewriter/show.aspx?id=$1</rewrite>
</rule>
</urlrewrites>
</system.web>
</configuration>
Notice how we have to escape the period in the url element such as 'show\.asp'. This is a Regular Expression escape and it's a small price to pay for the flexibility of regular expressions. These also show how we set-up a capturing expression using (.*) in the <url> element and refer to that capture in the <rewrite> element with $1
Configuration Section Handlers
.Net's configuration mechanism requires us to write code as a "handler" for this section. Here's the code for that:
Collapse
<configuration>
<configSections>
<sectionGroup name="system.web">
<section name="urlrewrites" type="ThunderMain.URLRewriter.Rewriter,
ThunderMain.URLRewriter, Version=1.0.783.30976,
Culture=neutral, PublicKeyToken=7a95f6f4820c8dc3"/>
</sectionGroup>
</configSections>
</configuration>
This section handler specifies that for every section called "urlrewrites", there is a class called ThunderMain.URLRewriter.Rewriter which can be found in the ThunderMain.URLRewriter.dll assembly with the given public key token. The public key token is required because this assembly has to be placed into the GAC and therefore given a strong name.
A section handler is defined as a class which implements the IConfigurationSectionHandler interface. This has one method, Create(), which should be implemented, and in our code that is very simple. It merely stores the urlrewrites element for later use:
Collapse
public object Create(object parent, object configContext, XmlNode section)
{
_oRules=section;
return this;
}
Initiating the rewrite process
Coming back to actually rewriting the URL, as I said earlier, we need to do something in the Application_BeginRequest() event in Global.asax - we just delegate this to another class:
Collapse
protected void Application_BeginRequest(Object sender, EventArgs e)
{
ThunderMain.URLRewriter.Rewriter.Process();
}
which calls the static method Process() on the Rewriter class. Process() first obtains a reference to the configuration section handler (which happens to be an instance of the current class) and then delegates most of the work to GetSubstitution() - an instance method of this class.
Collapse
public static void Process()
{
Rewriter oRewriter=
(Rewriter)ConfigurationSettings.GetConfig("system.web/urlrewrites");
string zSubst=oRewriter.GetSubstitution(HttpContext.Current.Request.Path);
if(zSubst.Length>0) {
HttpContext.Current.RewritePath(zSubst);
}
}
GetSubstitution() is just as simple - iterating through all possible URL Rewrites to see if one matches. If it does, it returns the new URL, otherwise it just returns the original URL:
Collapse
public string GetSubstitution(string zPath)
{
Regex oReg;
foreach(XmlNode oNode in _oRules.SelectNodes("rule")) {
oReg=new Regex(oNode.SelectSingleNode("url/text()").Value);
Match oMatch=oReg.Match(zPath);
if(oMatch.Success) {
return oReg.Replace(zPath,
oNode.SelectSingleNode("rewrite/text()").Value);
}
}
return zPath;
}
Installing the sample code
Extract the code into a URLRewriter folder, then turn this into a virtual directory using the Internet Information Services MMC control panel applet. Compile the code use the 'Make Rewriter.bat' batch script into the bin sub-folder. Then add bin/ThunderMain.URLRewriter.dll to the Global Assembly Cache by copying and pasting the dll into %WINDIR%\assembly using Windows Explorer. Finally, navigate to http://localhost/URLRewriter/default.aspx and try the demo URLs listed.
None will actually work because there's one last thing we have to be aware of...
Finally
There's one major caveat with all this. If you want to process a request with a file extension other than .aspx such as .asp or .html, then you need to change IIS to pass all requests through to the ASP.NET ISAPI extension. Unfortunately, you will need physical access to the server to perform this, which prevents you from simply XCOPY deploying your code to an ISP.
We've added the HEAD, GET and POST verbs to all files with .* file extension (ie all files) and mapped those to the ASP.NET ISAPI extension - aspnet_isapi.dll.
The complete range of mappings, including the new .* mapping.
for more details : http://www.codeproject.com/KB/aspnet/urlrewriter.aspx
