W3C Architecture Domain HTTP

HTTP Extension Framework

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

The HTTP Extension Framework describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies.

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.


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.


Current RFC

Latest Draft (Mar 15, 1999)

Scenarios and Issues


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


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.

Eric Prud'hommeaux,
@(#) $Id: Overview.html,v 1.32 2005/01/13 10:45:29 ylafon Exp $