geek-isms: cool URIs

Cool URIs

Way back when, I wrote a short summary of the issues I encountered while trying to coerce Apache, PHP and Multiviews into offering cool URIs on bmt-online. At the time, the conclusion was somewhat disabused, as I hadn't manage to find a satisfying solution to my issues.

Recently, I ran into a comment by Mark Tranchant in the PHP documentation describing issues similar to mine, linking back to a write-up of his with an interestingly similar title. I ended up sharing my thoughts on the subject with Mark, and ended up arriving to a conclusion very different with that of last time.

So…

The general issue here is that of the mapping of the URI space onto the file system. Many servers give the impressions that there is pretty much a one-on-one relationship between the two—as in select the root directory and anything under that directory will be served when called by its actual name relative to that directory—but it isn't necessarily so. The Multiviews system on Apache is pretty close to the one-on-one mapping, just adding some room to move as far as resource extension is concerned.

For the problem at hand, which boils down to hiding the php extension of the scripts used on the backend to serve the site's pages, I ended up thinking that Multiviews was a pretty poor solution for the following reasons:

1. to use Multiviews to map an extension-less URI on a unique file with extension is an abuse of the mechanism, as it was designed to map the extension-less URI on one of a variety of files depending on the negotiation taking place. In other words, as far as the PHP documents are concerned, there is ever one choice for the Multiviews algorithm to choose from as opposed as, e.g. a language negotiation with a handful of documents in various languages. This is the weak argument. After all, the web master is the only one to know about the abuse, and it is quite inconsequential.
2. as explained in the first article about the subject and in Mark's article, the solution, as practicable with Apache 1.3—things are a little better with Apache 2.0—is not satisfying for picky clients because of the application/x-httpd-php MIME type tagged to the PHP scripts.
3. Multiviews requires that a MIME type be assigned to the PHP scripts, regardless of their actual output. In the worse—Apache 1.3—case, I had to assign them the internal type application/x-httpd-php; in the better—Apache 2.0—case, Mark assigned them text/htmlfor the purpose of content negotiation. In any case, our scripts serve application/xhtml+xml or text/html depending on the declared abilities of the user agent.

Thus, the use of Multiviews in this context is not much more than a hack, which works for some definition of work, and this is not quite satisfying for those who are trying to pay attention to the detail.

As a conclusion, I am pretty much ok with letting go of Multiviews to solve the URI-to-file system issue. My current solution is a mix of DirectoryIndex directives—that include index.php for directory index files—for URIs such as http://www.bmt-online.org or http://www.bmt-online.org/archives/2004/04—and Alias directives that map extension-less URIs to .php files—e.g. Alias /employment E:/htdocs/www/employment.php—for most other URIs.

This solution is a little unwieldy—especially as it requires an Alias entry per page on the site—but I feel is totally manageable for a small size web site such as bmt-online. The next step would involve mastering some of mod_rewrite to obtain the same aliasing results in a more concise way. Eventually, larger sites might want to involve a lookup step a through some sort of database to map an URL onto a local resource on the file system.

fri 2004-04-16