Usage Patterns For Client-Side URI parameters

W3C Working Draft 15 April 2009

This version:
Latest version:
T. V. Raman <raman@google.com >

This document is also available in these non-normative formats: XML.


Designers of URIs have traditionally used ? to encode server-side parameters. At its inception, the Web also introduced fragment identifiers (preceded by # ) as a means of addressing specific locations in a document. As highly interactive applications get built using Web parts (HTML, CSS and JavaScript component resources that are themselves Web addressible — see [tvr-cacm2009], there is an increasing need for encoding interaction state as part of the URI. The Web is beginning to discover and codify design patterns based on fragment identifiers for many of these use cases.

This draft finding is being prepared in response to TAG issue #60 . This document explores the issues that arise in this context, and attempts to define best practices that help:

The goal of this finding is to initially collect the various usage scenarios that are leading to innovative uses of client-side URI parameters, along with the solutions that have been developed by the Web community. When this exercise is complete, this finding will conclude by ensuring that these design patterns are mutually compatible. If some of these usage patterns are identified as being in conflict, we will recommend best practices that help side-step such conflicts. We encourage the wider Web community to point us at emerging usage scenarios and design patterns so that we maximize our chances of arriving at a final finding that helps move forward the architecture of the Web in a self-consistent manner.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document has been developed for discussion by the W3C Technical Architecture Group . An earlier version, dated March 20, 2008, was made publicly available as a draft TAG finding, but not as a formal W3C working draft. The TAG decided at its 2 April 2009 teleconference to publish this version as a First Public Working Draft in order to get additional input from the Web community. Sections that need additional work are intentionally left as empty place-holder sections so that the Web community gets a sense of where we would like to take this document.

Although this issue has been under discussion within the TAG and on its public discussion list, publication as a Working Draft does not imply that these discussions are complete or that the TAG has reached consensus on recommendations in this area.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org ( archive ).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
2 Use Case Scenarios
    2.1 Addressing Into Multimedia Streams
        2.1.1 Things To Note
        2.1.2 Extrapolating From This Pattern
        2.1.3 Architectural Questions
    2.2 Interaction State And Browser History
    2.3 AJAX Libraries And State Management
    2.4 Web Command Lines
    2.5 Passing Data Among Frames
    2.6 The Naked Hash-Ref
3 Recommended Best Practices
4 Affected Communities To Liaise With
5 Conclusions
6 Open Issues
7 References

1 Introduction

At the beginning of the Web, we decided to encode server-side URI parameters with a ? . At the same time, the Web adopted # to attach fragment identifiers to URIs so that user-agents could address into specific locations in an HTML document. Nearly 20 years later, the Web has built a strong set of conventions around how URI parameters are used. As transactional applications began moving on to the Web in the late 1990's, server-side parameters formed a core building block for how application state was communicated between client and server. In this phase of Web evolution, clients were still comparatively simple, and client-side URI parameters did not move beyond the use of fragment identifiers. But with Web 2.0 applications increasingly moving traditional client-side applications to the Web, we are now seeing a variety of design patterns beginning to emerge with respect to how client-side URI parameters are used in order to influence client interaction. The need to remain consistent with the prevalent Web architecture has seen these design patterns build on the existing mechanism of fragment identifiers in URIs. This finding enumerates the various emerging patterns along with their associated use cases as a means of documenting existing practice on the Web.

2 Use Case Scenarios

This section enumerates the various usage scenarios that are leading to innovative uses of client-side URI parameters on the Web.

2.1 Addressing Into Multimedia Streams

When publishing multimedia streams, there is often a need to address into specific points in the multimedia stream, e.g., by using a time-index. The simplest means of doing this is to pass in the start-time as a server-side parameter in the URI, e.g., http://www.example.com/media.stream?start=03:06:09 and have the server start streaming the content starting at 3 hours, 6 minutes and 9 seconds into the content. This has the additional side-benefit of creating distinct URIs for each point in the media stream and such URIs can be used to bookmark locations of interest.

It is also possible to leverage client-side parameters encoded as part of the URI (using a # ), where this pseudo fragment identifier is used by client-side scripts as an argument to be passed to an appropriate locator function. Consider the following example taken from cnn.com :

CNN uses links like the above for all the topical video segments that are published on its site. The URI in this case has the following components:

Component Value
Protocol http
Host www.cnn.com
Path video
Client Param #/video/tech/2008/02/19/vo.aus.sea.spider.ap

2.1.1 Things To Note

The browser is expected to do a GET of the URI leading up to the fragment, and the processing application, in this case, the JavaScript embedded in the HTML Response processes the portion of the URI following the # .
Note that in the general case, the JavaScript function that eventually processes the client param may not have been present in the original HTTP Response it may come from a Javascript library that was loaded as the result of a subsequent HTTP GET request as a result of a script in the text/html response.
The fragment identifier has been intentionally identified as a client parameter .
Treating it as a regular fragment identifier in this usage would result in one incorrectly inferring that the URI for the video resource being addressed is http://www.cnn.com/video .
This would result in all the video links on the CNN site getting the same URI.
Thus, the entire URI in this case is http://www.cnn.com/video/#/video/tech/2008/02/19/vo.aus.sea.spider.ap
A consumer of this URI who goes looking for an id within the Response that matches the #-suffix of this URI will fail.
The reported Content-Type for the resource is text/html . However the behavior of the #-suffix in this case is not defined by the HTML specification.
As used, the #-suffix is a first-class client parameter in that it gets consumed by a script that is served as part of the HTML document returned by the server upon receiving a GET request.
This embedded script examines the URI available to it as script variable content.location , strips off the # and uses the rest of the prefix as an argument to function that generates the actual URI.
Having constructed this content URI, the script then proceeds to instruct the browser to play the media at the newly constructed location.
Notice further that the behavior of a user-agent that does not execute the embedded JavaScript is different given this URI. Notice further that the HTTP Response headers do not give the client any indication that this is likely to be so.

2.2 Interaction State And Browser History

AKA make the back button do the right thing . For live examples of this design pattern, see GMail and Google Maps both of which take extreme care to ensure that the back button works as the user would expect. These applications use iframe proxies to achieve the desired effect.

2.3 AJAX Libraries And State Management

AJAX applications use features of Dynamic HTML (DHTML) to create highly reactive user experiences. Updates to the Web user interface in response to user actions no longer require a full page reload. Consequently, the user can perform a sequence of interaction steps while remaining on the same page at least as seen from the browser's perspective of content.location . This makes for a good user experience, except for the following:

Recording key points in the interaction flow, e.g., for bookmarking.
Providing intuitive behavior for the browser's history mechanism.
Snapshoting interaction state so that one can return to a partially completed task at a later time.

Today, many of the details of AJAX programming have been abstracted away by higher level toolkits such as Dojo [dojo] and [google-gwt]GWT. Management of interaction state and browser history is one of the key affordances implemented in these libraries. History mechanisms in AJAX libraries like GWT and Dojo share a lot in common, and the approach can be traced back to Really Simple History (RSH) . In addition, the mechanism described here has also been adopted by a recent update to GMail.

The basic premise is to keep track of the application's internal state in the uri fragment identifier. This works because updating the fragment doesn't typically cause the page to be reloaded. This approach has several benefits:

It's about the only way to control the browser's history reliably.
It provides good feedback to the user.
It's bookmarkable — i.e., the user can create a bookmark to the current state and save it, email it, or whatever.

3 Recommended Best Practices

This section will be populated upon completion of this finding. Note that the preceding sections have identified design patterns without prejudice — with a view to enumerating the pros and cons of the various idioms seen on the Web today.

4 Affected Communities To Liaise With

It is clear that we will need to liaise effectively with standard groups that are active in defining the formats and protocols that come together in turning an HTTP Response into an interactive user interface for a Web application. This section will be used to track these dependencies, and may be removed upon final publication of this document.

The WhatWG that presently defines the behavior of conforming HTML5 Web browsers in conjunction with the W3C HTMLWG.
The HTTP work in the IETF.

5 Conclusions

This section will be completed when this finding is ready for final publication as an officially approved TAG Finding.

6 Open Issues

7 References

Mail thread on WWW-TAG from 2007 that initiated some of these discussions. (See http://lists.w3.org/Archives/Public/www-tag/2007Jul/0148.html.)
JSONP: JSON With Padding (See http://ajaxian.com/archives/jsonp-json-with-padding.)
Comet Programming from Wikipedia (See http://en.wikipedia.org/wiki/Comet_(programming).)
Mark Birbeck: Using URLs To Pass Parameters To The Web (See http://internet-apps.blogspot.com/2007/11/using-urls-to-pass-parameters-to-web.html.)
Google Web Toolkit — Java software development framework that makes writing AJAX applications like Google Maps and GMail easy for developers taking care of browser and platform details. (See http://code.google.com/webtoolkit/.)
Toward 2^W — Beyond Web-2.0, T. V. Raman, Communications Of The ACM, ACM, New York. (See http://portal.acm.org/citation.cfm?id=1461945.)
The Javascript Toolkit by the Dojo Foundation. (See http://dojotoolkit.org/.)