Microsoft .NET framework 3.5 SP1 has been equipped with routing assembly which enables our website to have rich URL interactions. This fact is also amplified with the presence of current ASP.NET programming model called MVC (model, view, and controller). One of the interesting stuffs we can accomplish is extension-less URL, i.e. URL without extension.
For example, if we already has the following URL before: asp.net/product/asp-net-mvc-extension-less-url.aspx. Using extension-less URL, we can remove the .aspx word from the URL, so it becomes: asp.net/product/asp-net-mvc-extension-less-url.
Why would we do so? I mean why would we choose extension-less URL over URL with extension? Some people may think that it relates to search engine optimization (SEO). They may think that search engines prefer extension-less URL. Is that true?
Well, Scott Guthrie said in his blog that it is not true. He said that search engines ignore the filename extension and just treat it as another character within the URL. However, SEO is a fast moving space. Something that is not true today may become true in the future.
While it can be debatable talking about extension-less URL related with SEO, I still prefer it compared with URL with extension. Here are my reasons:
- It is 5 characters less.
- It talks clearly what I want to offer my customers. If my product is mango juice, then the URL should perfectly be /product/mango-juice. Additional .aspx extension will not add any value to my business.
- I can freely change my web server technology and platform while I still maintain the same URL for my products. Imagine that three or five years from now, Microsoft will likely to produce more advanced technology than ASP.NET but requires us to change .aspx file extension to other form.
With the launch of IIS 7, extension-less URL should become easier to deploy and manage. But, while it is not shipped yet, we are left with the only IIS 6 as our choice. Unlike IIS 7, IIS 6 needs to be configured first before it can handle extension-less URL seamlessly. Here are available configuration choices that we have:
Install an ISAPI filter that will intercept web requests before they are handled by IIS. This ISAPI filter will perform mapping from extension-less URL to the real URL with extension that further will be processed by ASP.NET engine. For example if we already setup .mvc as an ASP.NET extension, the ISAPI filter will map extension-less URL to URL with .mvc extension.
This option requires you to have administrative privilege in IIS. This privilege is required to install the ISAPI filter. If you have your dedicated server, this should be no problem. But this is not the case for the most of us who rely on hosting services to host our web. If you can convince the hosting service owner to install the ISAPI filter, you are lucky.
Turn on the IIS wildcard mapping option in IIS 6. By turning this option ON, all web requests will be handled by ASP.NET, regardless of the file extension. If all requests are handled by ASP.NET, you are free to write your own handler, or use existing handler to intercept extension-less URL.
The downside of this option is performance degradation, because all web request will be handled by ASP.NET, including static files like images, stylesheets, and javascripts. Normally static files are handled by IIS directly.
Let the extension-less URL be handled by IIS. Of course IIS will complain that it cannot find the file requested, and trigger error code 404. In IIS we can configure custom error page that will handle error code 404. We can perform URL mapping in this error handler.
While this option works, it can cause false reporting of website statistic, especially related with 404 error code.
So, none of the above options are natural and easy to do, especially in a hosting environment. However, we still have options to enable extension-less URL in IIS 6.0.
