On the most common Web server configurations, the path of a URL pointing to a given site maps directly to a space on its file system. The mapping is one-to-one, effectively rendering HTTP resources semantically equivalent to files.

In reality, an HTTP resource can exhibit many more dimensions than a file. Given the right infrastructure, a Web server can deliver many possible representations for a given resource, or even permute a resource on the fly. A common method of manipulating dynamic HTTP resources is through an essential part of the Web's interface: the URI.

This section proposes a manner of normalizing the effects on resources that can be manipulated through the URI path and query parameters.

Path Parameters

In progress

Query Strings

A query string is defined as a non-hierarchical component of a URI. The CGI specification, the conventions of which most Web applications inherit, further defines it as either a list of parameters separated by the + character or a bag of key-value pairs joined by = and delineated by either & or ; — but not both the list and bag at once.

The parameter-list form of the query string ?one+two+three was intended to pass directly into the command line of a CGI program. When the = character was present, the Web server's CGI implementation would instead place the unaltered query string in the QUERY_STRING environment variable and leave the command-line list empty.

It is worth noting that CGI libraries such as the venerable Perl implementation conflate the contents of the query string with content POSTed from HTML forms. This clearly innocent appeal to expedience has been propagated forward to ubiquitous products like PHP, eroding the idempotence of the GET HTTP method and confusing an entire generation of Web developers.

in progress, march 20 2009

The query component can depict a dictionary with textual keys. Since the the key-value pairs can be repeated, e.g. ?one=1&two=2&three=3&one=uno, each entry in the dictionary corresponds to a bag of values. If we respect the order of the query string, we get a sequence. If we prune duplicate values, we get a set or ordered set, respectively.

The purpose of the query component is to focus some aspect of the resource. By adding key-value data, you're saying you want some property of the resource to permute according to a certain value.

This dictionary can then be applied to various slots that take a dictionary-shaped object. This is nothing remarkable; virtually every Web application framework does it. What is remarkable, however, is where the dictionary is constructed.

The semantics of the sequential form of the URI query component are addressed more robustly elsewhere, and as such this form can probably be safely discarded in non-CGI Web applications to mitigate confusion.