Introduction
Search engines give lower rankings to pages with parameters in the URL, but without parameters, our data-driven websites would be useless indeed. Thus the need for URL-rewriting, so we can pass parameters using other means.
Background
I originally tested out a few existing options, including one posted by Scott Guthrie, another one by Gaidar Magdanurov and a Code Project article by Manu Agrawal. In general, there were two issues that I encountered.
One, that the code/configuration required might not be so complex for rewriting the URL for a single ASPX page, but for a larger site with even ten ASPX pages requiring different parameters, these approaches required increasing amounts of code and configuration, either in the web.config file or in the code-behind for each ASPX page or both.
Two, many of the examples used the path separator ("/") to carry the parameters, such as http://[application root]/10/Customers.aspx to pass the customer ID "10". Of course, you're going to run into trouble accessing the CSS, JS and image files referenced in your code and even when those issues are resolved, none of those files will be cached because the client browser won't realize that the images are the same.
The solution is simple. First, let's use a dash ("-") instead of a slash ("/"). Adi�s, caching issues! Second, let's pass the name of the parameters together with their values. That way, we can use one approach to URL-rewrite all of our pages. Bienvenido, scalability! If our customers page was normally accessed at customers.aspx?cid=10, then the new URL would be cid-10-customers.aspx. All it takes is a few lines in the global.aspx file.
The Code
In Application_BeginRequest, we have to parse the requested file (Request.CurrentExecutionFilePath). The only complex part is the regular expression I used to pull out the parameters, but a recursive method would have worked just as well. The Regex is complied to increase performance.
Regex regex =
new Regex("(?<name>[^-|/]+)-(?<value>[^-]+)",RegexOptions.Compiled);
MatchCollection matches = regex.Matches(Request.CurrentExecutionFilePath);
The regular expression simply matches for name and value pairs separated by dashes; it collects the names and values in named groups. If the match is successful, it means that the requested page is URL rewritten and we have to reconstruct the "real" path using a StringBuilder.
StringBuilder sb = new StringBuilder();
sb.Append(
Request.CurrentExecutionFilePath.Substring(
Request.CurrentExecutionFilePath.LastIndexOf('-')+1)
);
This gives us the name of the ASPX file. Now it's time to add the parameters...
foreach (Match match in matches) {
sb.Append(match.Groups["name"].Value)
sb.Append("=");
sb.Append(match.Groups["value"].Value);
sb.Append("&");
}
sb.Remove(sb.Length - 1, 1);
That's it! Any ASPX page in your entire application can be referenced with SE-friendly URLs without having to write special code or configuration, or installing third-party components.
Points of Interest
- At first, I tried using *.html as the file extension for URL-rewritten pages. All it took was a small substitution of "html" for "aspx" when reconstructing the original URL and for some reason I got a kick out of seeing ASP.NET-processed pages looking as if they were static HTML files! However, this approach didn't work on some servers that were configured to bypass ASP.NET for HTML files. If your application is hosted on a server that you don't have complete access to, it's better to stick with the *.aspx extension.
- Obvious limitation: don't name any of your ASPX pages with a dash!
History
- 6 November, 2007 -- Original version posted
