The mystery of the trailing slash and the relative url

I had heard conflicting rumours about the significance of the trailing slash, so I decided to go googling.  If you explore the first few hits you will find all sorts of discussions about cool urls, the impact on SEO, the performance benefits of avoiding server redirects, amongst other stuff.  However, I found nothing that seemed to have a critical impact on the functionality of a web application.

My interest in the trailing slash had been provoked by my attempts to use relative urls in some documents that I was returning from a REST server.  Sometimes the relative urls would work sometimes they wouldn’t.

The performance benefit discussion that I had found related to the fact that web servers will automatically redirect to an url with the trailing slash if the last segment points to a folder instead of file. 

e.g. A request to http://example.org/folder would actually be redirected to http://example.org/folder/default.htm (or whatever file is set as the default file)

As is probably obvious to anyone who has done any amount of web development, all relative urls processed by a web server are relative to the folder in which the containing file is located.  Mechanically, this means the last segment is of the url is stripped of and the relative url is added.  A detailed explanation of how a relative url is resolved can be found here.

The key point that I want to draw attention to is that the behaviour is pretty natural when you are pulling static files from folders on a web server.  It gets less obvious when you start using dynamically generated resources with the style of urls that are common in the REST world.

E.g.  Say you retrieve a resource such as http://example.org/customer/101 and it contains an element <link href=”address”/>.  Common sense dictates that you are trying to get to http://example.org/customer/101/address, but that is not how it would be resolved.  The url would actually be resolved as http://example.org/customer/address

The problem is that the server no longer has a file/folder distinction, so the routing infrastructure doesn’t know whether it should append a slash to your url or not.

From what I’ve seen of Microsoft’s new URL routing infrastructure that is used by ASP.NET MVC and the WCF Rest toolkits, the url gets passed through with or without the slash depending on what the user typed.  This is a problem if you want to use relative urls in your representations.

I decided that I would include xml:base in documents so that at least I could be explicit about where my relative urls were relative to.  This way I don’t care if the source url ends with a slash or not.  I make sure that all my xml:base urls end in a slash and so far this strategy is working for me.