Why Extensions? | HTTP Activity | Specs | Mailing list | Software
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.
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.
Recent discussion has taken place on the <email@example.com> (Archives). However, you can also use the <firstname.lastname@example.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.
Some alternatives to HTTP Extensions have been suggested:
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.