HTTP Extension Framework

Why Extensions? | HTTP Activity | Specs | Mailing list | Software

Why Extensions?

Although HTTP has been designed as part of a relatively small group of people within the IETF HTTP Working Group (including myself), Henrik Frystyk Nielsen (the author) claims that this group in fact does not control the protocol. HTTP is considered a "common good" and has been extended locally as well as globally in ways that few could predict. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms.

These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. As a result extensions are often applied in an ad hoc manner which does not promote reusability nor interoperability.

The HTTP Extension Framework is a simple yet powerful mechanism for extending HTTP by describing which extensions are introduced along with information about who the recipient is, and how the recipient should deal with them.

Caching

HTTP exposes three common interfaces, GET, PUT, and POST, for retrieving and manipulating data. GET requests may be cached and must be, from the perspective of the user, repeatable and free of side-effects. GET requests have headers and no body. HTTP extensions provides a way of adding parameters to GET that are visible to HTTP. (URL manipulations, for instance, CGI parameters, should be opaque to HTTP.) Because these parameters appear in headers, they can be used to index caches by placing the name of the header in the Vary header when appropriate.

PUT and POST requests have a body but like the GET URL, the contents are considered opaque to HTTP.

Mailing List

Recent discussion has taken place on the <discuss@apps.ietf.org> (Archives). However, you can also use the <ietf-http-ext@w3.org> mailing list (Archives). Note, that you MUST be subscribed in order to post to this mailing list. Follow these shortcuts to quick subscribe or quick unsubscribe or see the information on mailing lists for more details.

Specifications

Current RFC

• HTTP Extension Framework RFC2774

Latest Draft (Mar 15, 1999)

• HTTP Extension Framework released Mar 15 1999 (plain)
• Postscript version with change bars from the 01 draft

Scenarios and Issues

• Comparison of alternatives
• Extensive set of scenarios
• Issues list - what's missing

Alternatives

Some alternatives to HTTP Extensions have been suggested:

SOAP headers

SOAP is an XML message format designed for machine to machine communications. It has an required/optional extension mechanism similar to the semantics of HTTP Extensions. (see discussion of SOAP and HTTP Extensions.)

HTTP Query

This method is similar to a GET except that the body is part of the index for the cache. While there is no formal limit to the size of a URL, popular web agents have hard limits (for instance, 1024 for apache). A script that transforms images would likely need to pass the image to be transformed in the body of a POST. Such an operation is cachable and free of side effects, contrary to the semantics of POST. HTTP Query provides these semantics.

Note - HTTP Query breaks the semantics that any proxying web agent need only look at the headers. As soon as the header has ended, it may evaluate the request and, if passing the data on to another server, stream the rest of the request in a more efficient manner.

Previous Drafts

• HTTP Extension Framework released Jan 20 1999 (plain) (ps) and postscript version with change bars from the 01 draft
• HTTP Extension Framework (submitted as Internet Draft August 7, 1998)
• Mandatory draft (submitted as ID Mar 13, 1998)
• Mandatory draft (submitted as ID Jan 20, 1998)

Software

The W3C Jigsaw server has a Java based implementation of the extension framework and the libwww client side library will soon have a sample implementation in C. Implementations are underway for Mozilla and Apache 2. Please see the W3C OpenSource code for more details.