RFC 2774 (rfc2774) - Page 3 of 20
An HTTP Extension Framework
Alternative Format: Original Text Document
RFC 2774 An HTTP Extension Framework February 2000
1. Introduction
This proposal is designed to address the tension between private
agreement and public specification; and to accommodate dynamic
extension of HTTP clients and servers by software components. The
kind of extensions capable of being introduced range from:
o extending a single HTTP message;
o introducing new encodings;
o initiating HTTP-derived protocols for new applications; to...
o switching to protocols which, once initiated, run independent
of the original protocol stack.
The proposal is intended to be used as follows:
o Some party designs and specifies an extension; the party
assigns the extension a globally unique URI, and makes one or
more representations of the extension available at that address
(see section 8).
o An HTTP client or server that implements this extension
mechanism (hereafter called an agent) declares the use of the
extension by referencing its URI in an extension declaration in
an HTTP message (see section 3).
o The HTTP application which the extension declaration is
intended for (hereafter called the ultimate recipient) can
deduce how to properly interpret the extended message based on
the extension declaration.
The proposal uses features in HTTP/1.1 but is compatible with
HTTP/1.0 applications in such a way that extended applications can
coexist with existing HTTP applications. Applications implementing
this proposal MUST be based on HTTP/1.1 (or later versions of HTTP).
2. Notational Conventions
This specification uses the same notational conventions and basic
parsing constructs as RFC 2068 [5]. In particular the BNF constructs
"token", "quoted-string", "Request-Line", "field-name", and
"absoluteURI" in this document are to be interpreted as described in
RFC 2068 [5].
Nielsen, et al. Experimental