15
12/10
URL Rewriting
More specifically, the IIS version of URL rewriting. Everyone knows that Apache has mod_rewrite, but these tools on the Windows side seem to get less attention, which is upsetting to me, since IIS has about 20% of the web server market, being second only to Apache.
To me at least, the allure of stable ASP.NET support—mod_mono, while cool, is anything but stable (it doesn’t even have full support for System.Net.SmtpClient, a feature I’d think would be essential in a web development platform)—is enough of a reason to stick with IIS, and there there’s the fact that IIS 7.5 with FastCGI is wicked fast, even when hosting non-ASP.NET pages (eww PHP…).
Anyway, URL rewriting exists for IIS—mod_rewrite/Apache is not the only contender—and it’s very easy to use. It not only has a GUI which is added to the IIS Management Console, but you can also create rules through XML in web.config in much the same way you can with mod_rewrite/Apache and .htaccess.
URL rewriting is especially useful with things like what I posted about yesterday, since it allows things like raw HTTP request handling to be much more transparent to the user. Also: Even if you’ve rewritten the original URL, it can still be accessed by the server variable “HTTP_X_ORIGINAL_URL“, which allows you to create ASP.NET HTTP handlers which look at the original URL and do something based on it. For example, you could host images, but want to do some advanced analytics/request filtering which can’t be accomplished any other way. You can have the web server re-write all requests for image files (by making a rewrite rule which examines their file extension—regular expressions for the win!—and then rewrites the request to point to an *.ashx, which will then look up “HTTP_X_ORIGINAL_URL“, and use this to find the image, set the content type, and return the image, while seamlessly—from the user’s point-of-view—doing whatever filtering/analysis you want.
What I found coolest when I started using WordPress with the URL Rewrite Module installed, was the fact that WordPress has native support for it. When I enabled permalinks, it modified the web.config file for my “blog” folder automatically:

Here’s the XML that it wrote:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="wordpress" patternSyntax="Wildcard"> <match url="*"/> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/> </conditions> <action type="Rewrite" url="index.php"/> </rule></rules> </rewrite> </system.webServer> </configuration>
In case you can’t tell, this rewrites all requests to http://rleahy.ca/blog/* which aren’t either a physical file or directory to index.php—the heart of the WordPress system—WordPress then uses “HTTP_X_ORIGINAL_URL” to decide what to display, whether a permalinked blog post or something else.
This is quite different—and perhaps more flexible/desireable—than the usual/tradition manner of beautifying parameters embedded in URLs, which uses regex to reassign the parameters—disguised as folders—to a query string.


