Subscribe: Atom or RSS

Charlie has Cool URLs - Part 2

In my previous weblog entry, I said that it has been a four-step process by which I’ve given Charlie cool URLs. The first step was to implement URL rewriting, and was the topic of the previous entry. The second step was to remove any extensions from URLs, and that’s what I’ll talk about here.

Let’s look an one of Apple’s cool URLs:

www.apple.com/ipod

What is significant about this URL is that it contains no extension. The page name is just ipod, and not ipod.htm or ipod.aspx. Internet Information Services isn’t too keen on such URLs. If IIS receives a request for ipod.asp, it passes the request off to ASP for processing. If IIS receives a request for ipod.aspx, it passes the request off to ASP.NET for processing. If IIS receives a request for ipod.gif, it handles the request itself by simply returning the requested GIF image. But, by default, IIS does not know what to do with requests that have no extension. (In reality, IIS “tests” certain default documents, but that’s a bit beside the point here.)

But there is a trick to get IIS to pass to ASP.NET any request for a file with no extension. The trick is to use what is known as a wildcard mapping (.*) in IIS that points to ASP.NET. This wildcard mapping says to IIS, “Whatever request you get, no matter what its extension, or even if it has no extension, pass that request on to ASP.NET.”

So with this wildcard mapping, cool URLs with no extension can be used in an ASP.NET website. But there is a catch. The wildcard mapping has told IIS to pass all requests to ASP.NET. That means the ASP.NET application will handle requests for style.css, script.js, image.gif, photo.jpg, and so on. For the most part, this presents no problem. ASP.NET will use its StaticFileHandler to simply pick up the requested file and send it back, which is precisely what IIS would have done anyway. But even requests for image.gif and photo.jpg will be subject to the same processing as for page.aspx, including authentication and authorization checks. Moreover, if your application is logging requests, you’ll be logging every request for every little file.

There is another gotcha about using URLs with no extension. Previously, it was IIS that didn’t know what to do with a request for a file named ipod with no extension. We solved this by giving IIS a wildcard mapping that tells it to pass all requests onto ASP.NET. But this just passes onto the ASP.NET application the same problem. What should it do with a file named simply ipod?

Rather than let ASP.NET deal with this problem, Charlie will add the .aspx extension to any incoming request that does not have an extension. So, while the visitor sees /ipod in his or her browser, Charlie changes this to be /ipod.aspx before full processing of the request occurs. In the previous weblog entry, I described how a new line in the Web.config file told ASP.NET that all requests for an .aspx page should go to the PageBuilder class. So that is the process by which the user sees cool URLs with no extensions, but ASP.NET sees the .aspx extensions that it knows and loves. Charlie just performs a little slight of hand, adding the .aspx extension when ASP.NET is not looking, and thereby gets a cool URL such as /ipod to be handled by its PageBuilder class.

Getting back to the opportunity that presents itself with a wildcard mapping in IIS, Charlie must handle all requests for all file types. To save having to write a thousand words, I’ll draw a diagram that shows what happens, by default, to five separate requests to the Charlie application. Because IIS has been instructed to pass all requests through to ASP.NET, Charlie will need to handle the requests for page.aspx, style.css, script.js, image.gif, and photo.jpg. By default, the last four will be handled by ASP.NET’s built-in StaticFileHandler.

But Charlie would like to seize the opportunity that presents itself. Namely, Charlie can implement its own way of handling requests for CSS Stylesheets, JavaScript files, GIF images, and JPEG photos. That way, Charlie can elect what to do. Charlie can just pick up the requested file and return it, just as the StaticFileHandler would do. Or, Charlie can pick up the requested file and adjust it (such as adding a copyright notice) before returning it. Or, Charlie can dynamically create the file requested (such as creating a GIF graph). ASP.NET makes this easy. Here are the instructions we write in the Web.config file, followed by a diagram showing the result.

<httpHandlers>
    <add verb="*" path="*.aspx" type="PageHandler, AssemblyName"/>
    <add verb="*" path="*.css"  type="CssHandler,  AssemblyName"/>
    <add verb="*" path="*.js"   type="JSHandler,   AssemblyName"/>
    <add verb="*" path="*.gif"  type="GifHandler,  AssemblyName"/>
    <add verb="*" path="*.jpg"  type="JpegHandler, AssemblyName"/>
</httpHandlers>

As I write this, I have not yet created the extra handlers. However, my little alisterjones.com website has these extra handlers, so it will be a simple matter. I’ll write about the handlers when I add them to Charlie.

So there you have a description of how Charlie’s URLs are so cool they don't even have extensions in them, and how Charlie is able to handle all requests for all files for all websites it serves.

by Alister Jones | Next up: Charlie has Cool URLs - Part 3 →

1 comments

----

Recent Posts

• Charlie has Cool URLs - Part 1
• The Two Devils of SQL
• Charlie’s Alarm Clock
• The EntityCache Object
• A Word on Lazy Loading
• The Cache is a Shadow, Not a Box
• Sunken Ships and Pirates
• The Provider Model, Unveiled
• The Magician and the Teacher
• The Practical Man