< draft-frystyk-http-extensions-02.txt   draft-frystyk-http-extensions-03.txt >
INTERNET-DRAFT HTTP Extensions H. Frystyk Nielsen, W3C INTERNET-DRAFT HTTP Extensions H. Frystyk Nielsen, W3C
draft-frystyk-http-extensions-02 P. Leach, Microsoft draft-frystyk-http-extensions-03 P. Leach, Microsoft
Scott Lawrence, Agranat Systems Scott Lawrence, Agranat Systems
Expires: Jul 20, 1999 Wed, Jan 20, 1999 Expires: Sep 15, 1999 Mon, Mar 15, 1999
HTTP Extension Framework HTTP Extension Framework
Status of this Document Status of this Document
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the Internet-Drafts are working documents of the Internet Engineering Task
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Force (IETF), its areas, and its working groups. Note that other
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), groups may also distribute working documents as Internet-Drafts.
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Internet-Drafts are draft documents valid for a maximum of six months
ftp.isi.edu (US West Coast). and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
Distribution of this document is unlimited. Please send comments to The list of current Internet-Drafts can be accessed at
the <ietf-http-ext@w3.org> mailing list. This list is archived at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
"http://lists.w3.org/Archives/Public/ietf-http-ext/". Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
Abstract General information about this document is linked from
"http://www.w3.org/Protocols/HTTP/ietf-http-ext/". Send comments to
the <ietf-http-ext@w3.org> mailing list. This list is archived at
"http://lists.w3.org/Archives/Public/ietf-http-ext/".
A wide range of applications have proposed various extensions of the Abstract
HTTP protocol. 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. This document 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.
The proposal associates each extension with a globally unique
identifier, and uses HTTP header fields to carry the extension
identifier and related information between the parties involved in the
extended communication.
Table of Contents A wide range of applications have proposed various extensions of the
HTTP protocol. 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. This document 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.
The proposal associates each extension with a globally unique
identifier, and uses HTTP header fields to carry the extension
identifier and related information between the parties involved in the
extended communication.
1. Introduction............................................... 2 Table of Contents
2. Notational Conventions..................................... 3 1. Introduction ...............................................2
3. Extension Declarations..................................... 3 2. Notational Conventions .....................................3
3.1 Header Field Prefixes................................... 4 3. Extension Declarations .....................................3
4. Extension Header Fields.................................... 5 3.1 Header Field Prefixes ...................................4
4.1 End-to-End Extensions................................... 6 4. Extension Header Fields ....................................6
4.2 Hop-by-Hop Extensions................................... 6 4.1 End-to-End Extensions ...................................6
4.3 Extension Response Header Fields........................ 7 4.2 Hop-by-Hop Extensions ...................................7
5. Mandatory HTTP Requests.................................... 7 4.3 Extension Response Header Fields ........................7
5.1 Fulfilling a Mandatory Request.......................... 9 5. Mandatory HTTP Requests ....................................8
6. Mandatory HTTP Responses.................................. 10 5.1 Fulfilling a Mandatory Request ..........................9
7. 510 Not Extended.......................................... 10 6. Mandatory HTTP Responses ..................................10
8. Publishing an Extension................................... 10 7. 510 Not Extended ..........................................11
9. Caching Considerations.................................... 12 8. Publishing an Extension ...................................11
10. Security Considerations.................................. 12 9. Caching Considerations ....................................12
11. References............................................... 12 10. Security Considerations ...................................13
12. Acknowledgements......................................... 13 11. References ................................................13
13. Authors Addresses........................................ 13 12. Acknowledgements ..........................................13
14. Summary of Protocol Interactions......................... 13 13. Authors Addresses .........................................14
15. Examples................................................. 14 14. Summary of Protocol Interactions ..........................14
15.1 User Agent to Origin Server............................ 15 15. Examples ..................................................15
15.2 User Agent to Origin Server via HTTP/1.1 Proxy......... 15 15.1 User Agent to Origin Server ............................15
15.3 User Agent to Origin Server via HTTP/1.0 Proxy......... 16 15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........16
15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........17
1. Introduction 1. Introduction
This proposal is designed to address the tension between private This proposal is designed to address the tension between private
agreement and public specification; and to accommodate dynamic agreement and public specification; and to accommodate dynamic
extension of HTTP clients and servers by software components. The kind extension of HTTP clients and servers by software components. The kind
of extensions capable of being introduced range from: of extensions capable of being introduced range from:
o extending a single HTTP message; 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 introducing new encodings;
o Some party designs and specifies an extension; the party assigns o initiating HTTP-derived protocols for new applications; to...
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 o switching to protocols which, once initiated, run independent of
applications in such a way that extended applications can coexist with the original protocol stack.
existing HTTP applications. Applications implementing this proposal
MUST be based on HTTP/1.1 (or later versions of HTTP).
2. Notational Conventions The proposal is intended to be used as follows:
This specification uses the same notational conventions and basic o Some party designs and specifies an extension; the party assigns
parsing constructs as RFC 2068 [5]. In particular the BNF constructs the extension a globally unique URI, and makes one or more
"token", "quoted-string", "Request-Line", "field-name", and representations of the extension available at that address (see
"absoluteURI" in this document are to be interpreted as described in section 8).
RFC 2068 [5].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", o An HTTP client or server that implements this extension mechanism
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this (hereafter called an agent) declares the use of the extension by
document are to be interpreted as described in RFC 2119 [6]. referencing its URI in an extension declaration in an HTTP
message (see section 3).
This proposal does not rely on particular features defined in URLs [8] o The HTTP application which the extension declaration is intended
that cannot potentially be expressed using URNs (see section 8). for (hereafter called the ultimate recipient) can deduce how to
Therefore, the more generic term URI [8] is used throughout the properly interpret the extended message based on the extension
specification. declaration.
3. Extension Declarations 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).
An extension declaration can be used to indicate that an extension has 2. Notational Conventions
been applied to a message and possibly to reserve a part of the header
namespace identified by a header field prefix (see 3.1). This section
defines the extension declaration itself; section 4 defines a set of
header fields using the extension declaration.
This specification does not define any ramifications of applying an This specification uses the same notational conventions and basic
extension to a message nor whether two extensions can or cannot parsing constructs as RFC 2068 [5]. In particular the BNF constructs
logically coexist within the same message. It is simply a framework "token", "quoted-string", "Request-Line", "field-name", and
for describing which extensions have been applied and what the "absoluteURI" in this document are to be interpreted as described in
ultimate recipient either must or may do in order to properly RFC 2068 [5].
interpret any extension declarations within that message.
The grammar for an extension declaration is as follows: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6].
ext-decl = <"> ( absoluteURI | field-name ) <"> This proposal does not rely on particular features defined in URLs [8]
[ namespace ] [ decl-extensions ] that cannot potentially be expressed using URNs (see section 8).
Therefore, the more generic term URI [8] is used throughout the
specification.
namespace = ";" "ns" "=" header-prefix 3. Extension Declarations
header-prefix = 2*DIGIT
decl-extensions = *( decl-ext ) An extension declaration can be used to indicate that an extension has
decl-ext = ";" token [ "=" ( token | quoted-string ) ] been applied to a message and possibly to reserve a part of the header
namespace identified by a header field prefix (see 3.1). This section
defines the extension declaration itself; section 4 defines a set of
header fields using the extension declaration.
An extension is identified by an absolute, globally unique URI or a This specification does not define any ramifications of applying an
field-name. A field-name MUST specify a header field uniquely defined extension to a message nor whether two extensions can or cannot
in an IETF Standards Track RFC [3]. A URI can unambiguously be logically coexist within the same message. It is simply a framework
distinguished from a field-name by the presence of a colon (":"). for describing which extensions have been applied and what the
ultimate recipient either must or may do in order to properly
interpret any extension declarations within that message.
The support for header field names as extension identifiers provides a The grammar for an extension declaration is as follows:
transition strategy from decentralized extensions to extensions
defined by IETF Standards Track RFCs until a mapping between the
globally unique URI space and features defined in IETF Standards Track
RFCs has been defined according to the guidelines described in section
8.
Examples of extension declarations are ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]
"http://www.company.com/extension"; ns=11 namespace = ";" "ns" "=" header-prefix
"Range" header-prefix = 2*DIGIT
An agent MAY use the decl-extensions mechanism to include optional decl-extensions = *( decl-ext )
extension declaration parameters but cannot assume these parameters to decl-ext = ";" token [ "=" ( token | quoted-string ) ]
be recognized by the recipient. An agent MUST NOT use decl-extensions
to pass extension instance data, which MAY be passed using header
field prefix values (see section 3.1). Unrecognized decl-ext
parameters SHOULD be ignored and MUST NOT be removed by proxies when
forwarding the extension declaration.
3.1 Header Field Prefixes An extension is identified by an absolute, globally unique URI or a
field-name. A field-name MUST specify a header field uniquely defined
in an IETF Standards Track RFC [3]. A URI can unambiguously be
distinguished from a field-name by the presence of a colon (":").
The header-prefix is a dynamically generated string. All header fields The support for header field names as extension identifiers provides a
in the message that match this string, using string prefix-matching, transition strategy from decentralized extensions to extensions
belong to that extension declaration. Header field prefixes allow an defined by IETF Standards Track RFCs until a mapping between the
extension declaration to dynamically reserve a subspace of the header globally unique URI space and features defined in IETF Standards Track
space in a protocol message in order to prevent header field name RFCs has been defined according to the guidelines described in section
clashes and to allow multiple declarations using the same extension to 8.
be applied to the same message without conflicting.
Header fields using a header-prefix are of the form: Examples of extension declarations are
prefixed-header = prefix-match field-name "http://www.company.com/extension"; ns=11
prefix-match = header-prefix "-" "Range"
Linear white space (LWS) MUST NOT be used between the header-prefix
and the dash ("-") or between the prefix-match and the field-name. The
string prefix matching algorithm is applied to the prefix-match
string.
The format of the prefix using a combination of digits and the dash An agent MAY use the decl-extensions mechanism to include optional
("-") guarantees that no extension declaration can reserve the whole extension declaration parameters but cannot assume these parameters to
header field name space. The header-prefix mechanism was preferred be recognized by the recipient. An agent MUST NOT use decl-extensions
over other solutions for exchanging extension instance parameters to pass extension instance data, which MAY be passed using header
because it is header based and therefore allows for easy integration field prefix values (see section 3.1). Unrecognized decl-ext
of new extensions with existing HTTP features. parameters SHOULD be ignored and MUST NOT be removed by proxies when
forwarding the extension declaration.
Agents MUST NOT reuse header-prefix values in the same message unless 3.1 Header Field Prefixes
explicitly allowed by the extension (see section 4.1 for a discussion
of the ultimate recipient of an extension declaration).
Clients SHOULD be as consistent as possible when generating header- The header-prefix is a dynamically generated string. All header fields
prefix values as this facilitates use of the Vary header field in in the message that match this string, using string prefix-matching,
responses that vary as a function of the request extension belong to that extension declaration. Header field prefixes allow an
declaration(s) (see [5], section 13.6). extension declaration to dynamically reserve a subspace of the header
space in a protocol message in order to prevent header field name
clashes and to allow multiple declarations using the same extension to
be applied to the same message without conflicting.
Examples of header-prefix values are Header fields using a header-prefix are of the form:
12 prefixed-header = prefix-match field-name
15 prefix-match = header-prefix "-"
23
Old applications may introduce header fields independent of this Linear white space (LWS) MUST NOT be used between the header-prefix
extension mechanism, potentially conflicting with header fields and the dash ("-") or between the prefix-match and the field-name. The
introduced by the prefix mechanism. In order to minimize this risk, string prefix matching algorithm is applied to the prefix-match
prefixes MUST contain at least 2 digits. string.
4. Extension Header Fields The format of the prefix using a combination of digits and the dash
("-") guarantees that no extension declaration can reserve the whole
header field name space. The header-prefix mechanism was preferred
over other solutions for exchanging extension instance parameters
because it is header based and therefore allows for easy integration
of new extensions with existing HTTP features.
This proposal introduces two types of extension declaration strength: Agents MUST NOT reuse header-prefix values in the same message unless
mandatory and optional, and two types of extension declaration scope: explicitly allowed by the extension (see section 4.1 for a discussion
hop-by-hop and end-to-end (see section 4.1 and 4.2). of the ultimate recipient of an extension declaration).
A mandatory extension declaration indicates that the ultimate Clients SHOULD be as consistent as possible when generating header-
recipient MUST consult and adhere to the rules given by the extension prefix values as this facilitates use of the Vary header field in
when processing the message or reporting an error (see section 5 and responses that vary as a function of the request extension
7). declaration(s) (see [5], section 13.6).
An optional extension declaration indicates that the ultimate Servers including prefixed-header header fields in a Vary header field
recipient of the extension MAY consult and adhere to the rules given value MUST also include the corresponding extension declaration field-
by the extension when processing the message, or ignore the extension name as part of that value. For example, if a response depends on the
declaration completely. An agent may not be able to distinguish value of the 16-use-transform header field defined by an optional
whether the ultimate recipient does not understand an extension extension declaration in the request, the Vary header field in the
referred to by an optional extension or simply ignores the extension response could look like this:
declaration.
The combination of the declaration strength and scope defines a 2x2 Vary: Opt, 16-use-transform
matrix which is distinguished by four new general HTTP header fields:
Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also see
appendix 14, which has a table of interactions with origin servers and
proxies.)
The header fields are general header fields as they describe which Note, that header-prefix consistency is no substitute for including an
extensions actually are applied to an HTTP message. Optional extension declaration in the message: header fields with header-prefix
declarations MAY be applied to any HTTP message without any change to values not defined by an extension declaration in the same message are
existing HTTP semantics (see section 5 for how to apply mandatory not defined by this specification.
extension declarations to requests and section 6 for how to apply them
to responses).
4.1 End-to-End Extensions Examples of header-prefix values are
12
15
23
End-to-end declarations MUST be transmitted to the ultimate recipient Old applications may introduce header fields independent of this
of the declaration. The Man and the Opt general header fields are end- extension mechanism, potentially conflicting with header fields
to-end header fields and are defined as follows: introduced by the prefix mechanism. In order to minimize this risk,
prefixes MUST contain at least 2 digits.
mandatory = "Man" ":" 1#ext-decl 4. Extension Header Fields
optional = "Opt" ":" 1#ext-decl
For example This proposal introduces two types of extension declaration strength:
mandatory and optional, and two types of extension declaration scope:
hop-by-hop and end-to-end (see section 4.1 and 4.2).
HTTP/1.1 200 OK A mandatory extension declaration indicates that the ultimate
Content-Length: 421 recipient MUST consult and adhere to the rules given by the extension
Opt: "http://www.digest.org/Digest"; ns=15 when processing the message or reporting an error (see section 5 and
15-digest: "snfksjgor2tsajkt52" 7).
...
The ultimate recipient of a mandatory end-to-end extension declaration An optional extension declaration indicates that the ultimate
MUST handle that extension declaration as described in section 5 and recipient of the extension MAY consult and adhere to the rules given
6. by the extension when processing the message, or ignore the extension
declaration completely. An agent may not be able to distinguish
whether the ultimate recipient does not understand an extension
referred to by an optional extension or simply ignores the extension
declaration.
4.2 Hop-by-Hop Extensions The combination of the declaration strength and scope defines a 2x2
matrix which is distinguished by four new general HTTP header fields:
Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also see
appendix 14, which has a table of interactions with origin servers and
proxies.)
Hop-by-hop extension declarations are meaningful only for a single The header fields are general header fields as they describe which
HTTP connection. In HTTP/1.1, C-Man, C-Opt and all header fields with extensions actually are applied to an HTTP message. Optional
matching header-prefix values defined by C-Man and C-Opt MUST be declarations MAY be applied to any HTTP message if appropriate (see
protected by a Connection header field. That is, these header fields section 5 for how to apply mandatory extension declarations to
are to be included as Connection header field directives (see [5], requests and section 6 for how to apply them to responses).
section 14.10). The two header fields have the following grammar:
c-mandatory = "C-Man" ":" 1#ext-decl 4.1 End-to-End Extensions
c-optional = "C-Opt" ":" 1#ext-decl
For example
M-GET / HTTP/1.1 End-to-end declarations MUST be transmitted to the ultimate recipient
Host: some.host of the declaration. The Man and the Opt general header fields are end-
C-Man: "http://www.digest.org/ProxyAuth"; ns=14 to-end header fields and are defined as follows:
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
The ultimate recipient of a mandatory hop-by-hop extension declaration mandatory = "Man" ":" 1#ext-decl
MUST handle that extension declaration as described in section 5 and optional = "Opt" ":" 1#ext-decl
6.
4.3 Extension Response Header Fields For example
Two extension response header fields are used to indicate that a HTTP/1.1 200 OK
request containing mandatory extension declarations has been fulfilled Content-Length: 421
by the ultimate recipient as described in section 5.1. The extension Opt: "http://www.digest.org/Digest"; ns=15
response header fields are exclusively intended to serve as extension 15-digest: "snfksjgor2tsajkt52"
acknowledgements and can not carry any other information. ...
The Ext header field is used to indicate that all end-to-end mandatory The ultimate recipient of a mandatory end-to-end extension declaration
extension declarations in the request were fulfilled: MUST handle that extension declaration as described in section 5 and
6.
ext = "Ext" ":" 4.2 Hop-by-Hop Extensions
The C-Ext response header field is used to indicate that all hop-by- Hop-by-hop extension declarations are meaningful only for a single
hop mandatory extension declarations in the request were fulfilled. HTTP connection. In HTTP/1.1, C-Man, C-Opt, and all header fields with
matching header-prefix values defined by C-Man and C-Opt MUST be
protected by a Connection header field. That is, these header fields
are to be included as Connection header field directives (see [5],
section 14.10). The two header fields have the following grammar:
c-ext = "C-Ext" ":" c-mandatory = "C-Man" ":" 1#ext-decl
c-optional = "C-Opt" ":" 1#ext-decl
In HTTP/1.1, the C-Ext header fields MUST be protected by a Connection For example
header (see [5], section 14.10).
The Ext and the C-Ext header fields are not mutually exclusive; they M-GET / HTTP/1.1
can both occur within the same message as described in section 5.1. Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
5. Mandatory HTTP Requests The ultimate recipient of a mandatory hop-by-hop extension declaration
MUST handle that extension declaration as described in section 5 and
6.
An HTTP request is called a mandatory request if it includes at least 4.3 Extension Response Header Fields
one mandatory extension declaration (using the Man or the C-Man header
fields). The method name of a mandatory request MUST be prefixed by
"M-". For example, a client might express the binding rights-
management constraints in an HTTP PUT request as follows:
M-PUT /a-resource HTTP/1.1 Two extension response header fields are used to indicate that a
Man: "http://www.copyright.org/rights-management"; ns=16 request containing mandatory extension declarations has been fulfilled
16-copyright: http://www.copyright.org/COPYRIGHT.html by the ultimate recipient as described in section 5.1. The extension
16-contributions: http://www.copyright.org/PATCHES.html response header fields are exclusively intended to serve as extension
Host: www.w3.org acknowledgements, and can not carry any other information.
Content-Length: 1203
Content-Type: text/html
<!doctype html ... The Ext header field is used to indicate that all end-to-end mandatory
extension declarations in the request were fulfilled:
An ultimate recipient conforming to this specification receiving a ext = "Ext" ":"
mandatory request MUST process the request by performing the following
actions in the order listed below:
1. Identify all mandatory extension declarations (both hop-by-hop The C-Ext response header field is used to indicate that all hop-by-
and end-to-end); the server MAY ignore optional declarations hop mandatory extension declarations in the request were fulfilled.
without affecting the result of processing the HTTP message;
2. Examine all extensions identified in 1) and determine if they
are supported for this message. If not, respond with a 510 (Not
Extended) status-code (see section 7);
3. If 2) did not result in a 510 (Not Extended) status code, then
strip the "M-" prefix from the method name and process the
remainder of the request according to the semantics of the
extensions and of the existing HTTP method name as defined in
HTTP/1.1 [5] or later versions of HTTP.
4. If the evaluation in 3) was successful and the mandatory
request fulfilled, the server MUST respond as defined in
section 5.1. A server MUST NOT fulfill a request without
understanding and obeying all mandatory extension
declaration(s) in a request.
A proxy that does not act as the ultimate recipient of a mandatory c-ext = "C-Ext" ":"
extension declaration MUST NOT remove the extension declaration or the
"M-" method name prefix when forwarding the message. HTTP proxies that
do not understand the "M-" method name prefix SHOULD return 501 (Not
Implemented) or turn themselves into a tunnel (see [5]) in which case
they do not take any part in the communication.
A server receiving an HTTP/1.0 (or earlier versions of HTTP) message In HTTP/1.1, the C-Ext header fields MUST be protected by a Connection
that includes a Connection header MUST, for each connection-token in header (see [5], section 14.10).
this field, remove and ignore any header field(s) from the message
with the same name as the connection-token.
A server receiving a mandatory request including the "M-" method name The Ext and the C-Ext header fields are not mutually exclusive; they
prefix without any mandatory extension declarations to follow MUST can both occur within the same message as described in section 5.1.
return a 510 (Not Extended) response.
The "M-" prefix is reserved by this proposal and MUST NOT be used by 5. Mandatory HTTP Requests
other HTTP extensions.
5.1 Fulfilling a Mandatory Request An HTTP request is called a mandatory request if it includes at least
one mandatory extension declaration (using the Man or the C-Man header
fields). The method name of a mandatory request MUST be prefixed by
"M-". For example, a client might express the binding rights-
management constraints in an HTTP PUT request as follows:
A server MUST NOT claim to have fulfilled any mandatory request unless M-PUT /a-resource HTTP/1.1
it understood and obeyed all the mandatory extension declarations in Man: "http://www.copyright.org/rights-management"; ns=16
the request. This section defines a mechanism for conveying this 16-copyright: http://www.copyright.org/COPYRIGHT.html
information to the client in such a way that it interoperates with 16-contributions: http://www.copyright.org/PATCHES.html
existing HTTP applications and prevents broken servers from giving the Host: www.w3.org
false impression that an extended request was fulfilled by responding Content-Length: 1203
with a 200 (Ok) response without understanding the method. Content-Type: text/html
If any end-to-end mandatory extension declarations were among the <!doctype html ...
fulfilled extensions then the server MUST include an Ext response
header field in the response. In order to avoid that the Ext header
field inadvertently is cached in an HTTP/1.1 cache, the response MUST
contain a no-cache cache-control directive. If the response is
otherwise cachable, the no-cache cache-control directive SHOULD be
limited to only affect the Ext header field:
HTTP/1.1 200 OK An ultimate recipient conforming to this specification receiving a
Ext: mandatory request MUST process the request by performing the following
Cache-Control: no-cache="Ext" actions in the order listed below:
...
If the mandatory request has been forwarded by an HTTP/1.0 1. Identify all mandatory extension declarations (both hop-by-hop
intermediary proxy then this is indicated either directly in the and end-to-end); the server MAY ignore optional declarations
Request-Line or by the presence of an HTTP/1.1 Via header field. In without affecting the result of processing the HTTP message;
this case, the server MUST include an Expires header field with a date
equal to or earlier than the value of the Date header field. If the
response is otherwise cachable by HTTP/1.1 caches, the server SHOULD
include an appropriate max-age cache-control directive:
HTTP/1.1 200 OK 2. Examine all extensions identified in 1) and determine if they
Date: Sun, 25 Oct 1998 08:12:31 GMT are supported for this message. If not, respond with a 510 (Not
Expires: Sun, 25 Oct 1998 08:12:31 GMT Extended) status-code (see section 7);
Ext: 3. If 2) did not result in a 510 (Not Extended) status code, then
Cache-Control: no-cache="Ext", max-age=3600 process the request according to the semantics of the
... extensions and of the existing HTTP method name as defined in
HTTP/1.1 [5] or later versions of HTTP. The HTTP method name
can be obtained by ignoring the "M-" method name prefix.
If any hop-by-hop mandatory extension declarations were among the 4. If the evaluation in 3) was successful and the mandatory
fulfilled extensions then the server MUST include a C-Ext response request fulfilled, the server MUST respond as defined in
header field in the response. The C-Ext header field MUST be protected section 5.1. A server MUST NOT fulfill a request without
by a Connection header field (see [5], section 14.10). understanding and obeying all mandatory extension
declaration(s) in a request.
HTTP/1.1 200 OK A proxy that does not act as the ultimate recipient of a mandatory
C-Ext: extension declaration MUST NOT remove the extension declaration or the
Connection: C-Ext "M-" method name prefix when forwarding the message (see section 5.1
Note, that the Ext and C-Ext header fields are not mutually exclusive; for how to detect when a mandatory extension has been fulfilled).
they can be both be present in a response when fulfilling mandatory
request containing both hop-by-hop as well as end-to-end mandatory
extension declarations.
6. Mandatory HTTP Responses A server receiving an HTTP/1.0 (or earlier versions of HTTP) message
that includes a Connection header MUST, for each connection-token in
this field, remove and ignore any header field(s) from the message
with the same name as the connection-token.
A server MUST NOT include mandatory extension declarations in an HTTP A server receiving a mandatory request including the "M-" method name
response unless it is responding to a mandatory HTTP request whose prefix without any mandatory extension declarations to follow MUST
definition allowed for the mandatory response or the server has some a return a 510 (Not Extended) response.
priori knowledge that the recipient can handle the extended response.
A server MAY include optional extension declarations in any HTTP
response (see section 4).
If a client is the ultimate recipient of a mandatory HTTP response The "M-" prefix is reserved by this proposal and MUST NOT be used by
containing mandatory extension declarations that either the client other HTTP extensions.
does not understand or does not want to use, then it SHOULD discard
the complete response as if it were a 500 (Internal Server Error)
response.
7. 510 Not Extended 5.1 Fulfilling a Mandatory Request
The policy for accessing the resource has not been met in the request. A server MUST NOT claim to have fulfilled any mandatory request unless
The server SHOULD send back all the information necessary for the it understood and obeyed all the mandatory extension declarations in
client to issue an extended request. It is outside the scope of this the request. This section defines a mechanism for conveying this
specification to specify how the extensions inform the client. information to the client in such a way that it interoperates with
existing HTTP applications and prevents broken servers from giving the
false impression that an extended request was fulfilled by responding
with a 200 (Ok) response without understanding the method.
If the 510 response contains information about extensions that were If any end-to-end mandatory extension declarations were among the
not present in the initial request then the client MAY repeat the fulfilled extensions then the server MUST include an Ext response
request if it has reason to believe it can fulfill the extension header field in the response. In order to avoid that the Ext header
policy by modifying the request according to the information provided field inadvertently is cached in an HTTP/1.1 cache, the response MUST
in the 510 response. Otherwise the client MAY present any entity contain a no-cache cache-control directive. If the response is
included in the 510 response to the user, since that entity may otherwise cachable, the no-cache cache-control directive SHOULD be
include relevant diagnostic information. limited to only affect the Ext header field:
8. Publishing an Extension HTTP/1.1 200 OK
Ext:
Cache-Control: no-cache="Ext"
...
While the protocol extension definition should be published at the If the mandatory request has been forwarded by an HTTP/1.0
address of the extension identifier, this is not a requirement of this intermediary proxy then this is indicated either directly in the
specification. The only absolute requirement is that extension Request-Line or by the presence of an HTTP/1.1 Via header field. In
identifiers MUST be globally unique identifiers and that distinct this case, the server MUST include an Expires header field with a date
names be used for distinct semantics. equal to or earlier than the value of the Date header field (see
section 9 for a discussion on caching considerations):
Likewise, applications are not required to attempt resolving extension HTTP/1.1 200 OK
identifiers included in an extension declaration. The only absolute Date: Sun, 25 Oct 1998 08:12:31 GMT
requirement is that an application MUST NOT claim conformance with an Expires: Sun, 25 Oct 1998 08:12:31 GMT
extension that it does not recognize regardless of whether it has Ext:
tried to resolve the extension identifier or not. This document does Cache-Control: no-cache="Ext", max-age=3600
not provide any policy for how long or how often an application may ...
attempt to resolve an extension identifier.
The association between the extension identifier and the specification If any hop-by-hop mandatory extension declarations were among the
might be made by distributing a specification, which references the fulfilled extensions then the server MUST include a C-Ext response
extension identifier. header field in the response. The C-Ext header field MUST be protected
by a Connection header field (see [5], section 14.10).
It is strongly recommended that the integrity and persistence of the HTTP/1.1 200 OK
extension identifier be maintained and kept unquestioned throughout C-Ext:
the lifetime of the extension. Care should be taken not to distribute Connection: C-Ext
conflicting specifications that reference the same name. Even when an
extension specification is made available at the address of the URI,
care must be taken that the specification made available at that
address does not change over time. One agent may associate the
identifier with the old semantics, and another might associate it with
the new semantics.
The extension definition may be made available in different Note, that the Ext and C-Ext header fields are not mutually exclusive;
representations ranging from they can be both be present in a response when fulfilling mandatory
request containing both hop-by-hop as well as end-to-end mandatory
extension declarations.
o a human-readable specification defining the extension semantics 6. Mandatory HTTP Responses
(see for example [7]),
o downloadable code which implements the semantics defined by the
extension,
o a formal interface description provided by the extension, to
o a machine-readable specification defining the extension
semantics.
For example, a software component that implements the specification A server MUST NOT include mandatory extension declarations in an HTTP
may reside at the same address as a human-readable specification response unless it is responding to a mandatory HTTP request whose
(distinguished by content negotiation). The human-readable definition allowed for the mandatory response or the server has some a
representation serves to document the extension and encourage priori knowledge that the recipient can handle the extended response.
deployment, while the software component allows clients and servers to A server MAY include optional extension declarations in any HTTP
be dynamically extended. response (see section 4).
9. Caching Considerations If a client is the ultimate recipient of a mandatory HTTP response
containing mandatory extension declarations that either the client
does not understand or does not want to use, then it SHOULD discard
the complete response as if it were a 500 (Internal Server Error)
response.
Use of extensions using the syntax defined by this document may have 7. 510 Not Extended
additional implications on the cachability of HTTP response messages
other than the ones described in section 5.1.
The originator of an extended message should be able to determine from The policy for accessing the resource has not been met in the request.
the semantics of the extension whether or not the extension's presence The server should send back all the information necessary for the
impacts the cachability of the response message. If an extension does client to issue an extended request. It is outside the scope of this
change the default cachability of the response, the originator MUST specification to specify how the extensions inform the client.
include a Cache-Control header field containing the cache directives
corresponding to the desired result of the extended semantics.
10. Security Considerations If the 510 response contains information about extensions that were
not present in the initial request then the client MAY repeat the
request if it has reason to believe it can fulfill the extension
policy by modifying the request according to the information provided
in the 510 response. Otherwise the client MAY present any entity
included in the 510 response to the user, since that entity may
include relevant diagnostic information.
Dynamic installation of extension facilities as described in the 8. Publishing an Extension
introduction involves software written by one party (the provider of
the implementation) to be executed under the authority of another (the
party operating the host software). This opens the host party to a
variety of "Trojan horse" attacks by the provider, or a malicious
third party that forges implementations under a provider's name. See,
for example RFC2046 [4], section 4.5.2 for a discussion of these
risks.
11. References While the protocol extension definition should be published at the
address of the extension identifier, this specification does not
require it. The only absolute requirement is that extension
identifiers MUST be globally unique identifiers, and that distinct
names be used for distinct semantics.
[1] D. H. Crocker. "Standard for the Format of ARPA Internet Text Likewise, applications are not required to attempt resolving extension
Messages", STD 11, RFC 822, UDEL, August 1982 identifiers included in an extension declaration. The only absolute
[2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer requirement is that an application MUST NOT claim conformance with an
Protocol -- HTTP/1.0", RFC 1945, W3C/MIT, UC Irvine, W3C/MIT, May extension that it does not recognize (regardless of whether it has
1996. tried to resolve the extension identifier or not). This document does
[3] S. Bradner, "The Internet Standards Process -- Revision 3", RFC not provide any policy for how long or how often an application may
2026, Harvard University, October 1996 attempt to resolve an extension identifier.
[4] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual,
November 1996.
[5] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine,
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997
[7] L. Masinter, "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, Xerox PARC, 1 April 1998
[8] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 12, 1998
[9] H. F. Nielsen, D. Connolly, R. Khare, "PEP - an extension
mechanism for HTTP", draft-http-pep-05.txt, November 21, 1997.
This work has expired
12. Acknowledgements The association between the extension identifier and the specification
might be made by distributing a specification, which references the
extension identifier.
Roy Fielding, Rohit Khare, and Yaron Y. Goland deserve special It is strongly recommended that the integrity and persistence of the
recognition for their efforts in commenting in all phases of this extension identifier be maintained and kept unquestioned throughout
specification. Also thanks to Josh Cohen, Ross Patterson, Jim Gettys, the lifetime of the extension. Care should be taken not to distribute
Larry Masinter, and to the people involved in PEP [9]. conflicting specifications that reference the same name. Even when an
extension specification is made available at the address of the URI,
care must be taken that the specification made available at that
address does not change over time. One agent may associate the
identifier with the old semantics, while another might associate it
with the new semantics.
The contribution of World Wide Web Consortium (W3C) staff is part of The extension definition may be made available in different
the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity"). representations ranging from
13. Authors Addresses o a human-readable specification defining the extension semantics
(see for example [7]),
Henrik Frystyk Nielsen o downloadable code which implements the semantics defined by the
Technical Staff, World Wide Web Consortium extension,
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Email: frystyk@w3.org
Paul J. Leach o a formal interface description provided by the extension, to
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
Email: paulle@microsoft.com
Scott Lawrence o a machine-readable specification defining the extension
Agranat Systems, Inc. semantics.
1345 Main Street
Waltham, MA 02154, USA
Email: lawrence@agranat.com
Appendices For example, a software component that implements the specification
may reside at the same address as a human-readable specification
(distinguished by content negotiation). The human-readable
representation serves to document the extension and encourage
deployment, while the software component would allow clients and
servers to be dynamically extended.
14. Summary of Protocol Interactions 9. Caching Considerations
The following tables summarize the outcome of strength and scope rules Use of extensions using the syntax defined by this document may have
of the mandatory proposal of compliant and non-compliant HTTP proxies additional implications on the cachability of HTTP response messages
and origin servers. The summary is intended as a guide and index to other than the ones described in section 5.1.
the text, but is necessarily cryptic and incomplete. This summary
should never be used or referenced separately from the complete
specification.
Table 1: Origin Server The originator of an extended message should be able to determine from
the semantics of the extension whether or not the extension's presence
impacts the caching constraints of the response message. If an
extension does require tighter constraints on the cachebility of the
response, the originator MUST include the appropriate combination of
cache header fields (Cache-Control, Vary, Expires) corresponding to
the required level of constraints of the extended semantics.
Scope Hop-by-hop End-to-end 10. Security Considerations
Strength Optional Required Optional Required Dynamic installation of extension facilities as described in the
(may) (must) (may) (must) introduction involves software written by one party (the provider of
the implementation) to be executed under the authority of another (the
party operating the host software). This opens the host party to a
variety of "Trojan horse" attacks by the provider, or a malicious
third party that forges implementations under a provider's name. See,
for example RFC2046 [4], section 4.5.2 for a discussion of these
risks.
Mandatory Standard 501 (Not Standard 501 (Not 11. References
unsupported processing Implemented)processing Implemented)
Extension Standard 510 (Not Standard 510 (Not [1] D. H. Crocker. "Standard for the Format of ARPA Internet Text
unsupported processing Extended) processing Extended) Messages", STD 11, RFC 822, UDEL, August 1982
[2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945, W3C/MIT, UC Irvine, W3C/MIT, May
1996.
[3] S. Bradner, "The Internet Standards Process -- Revision 3", RFC
2026, Harvard University, October 1996
[4] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual,
November 1996.
[5] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine,
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997
[7] L. Masinter, "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, Xerox PARC, 1 April 1998
[8] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 12, 1998
[9] H. F. Nielsen, D. Connolly, R. Khare, "PEP - an extension
mechanism for HTTP", draft-http-pep-05.txt, November 21, 1997.
This work has expired
Extension Extended Extended Extended Extended 12. Acknowledgements
supported processing processing processing processing
Table 2: Proxy Server Roy Fielding, Rohit Khare, Yaron Y. Goland, and Koen Holtman, deserve
special recognition for their efforts in commenting in all phases of
this specification. Also thanks to Josh Cohen, Ross Patterson, Jim
Gettys, Larry Masinter, and to the people involved in PEP [9].
Scope Hop-by-hop End-to-end The contribution of World Wide Web Consortium (W3C) staff is part of
the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity").
Strength Optional Required Optional Required 13. Authors Addresses
(may) (must) (may) (must)
Mandatory Strip 501 (Not Forward 501 (Not Henrik Frystyk Nielsen
unsupported extension Implemented)extension Implemented) Technical Staff, World Wide Web Consortium
or tunnel or tunnel MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Email: frystyk@w3.org
Extension Strip 510 (Not Forward Forward Paul J. Leach
unsupported extension Extended) extension extension Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
Email: paulle@microsoft.com
Extension Extended Extended Extended Extended Scott Lawrence
supported processing processing processing, processing, Agranat Systems, Inc.
and strip and strip may strip may strip 1345 Main Street
Waltham, MA 02154, USA
Email: lawrence@agranat.com
15. Examples Appendices
The following examples show various scenarios using mandatory in 14. Summary of Protocol Interactions
HTTP/1.1 requests and responses. Information not essential for
illustrating the examples is left out (referred to as "...")
15.1 User Agent to Origin Server
Table 3: User Agent directly to origin server The following tables summarize the outcome of strength and scope rules
of the mandatory proposal of compliant and non-compliant HTTP proxies
and origin servers. The summary is intended as a guide and index to
the text, but is necessarily cryptic and incomplete. This summary
should never be used or referenced separately from the complete
specification.
Client issues a M-GET /some-document HTTP/1.1 Table 1: Origin Server
request with one Opt: "http://www.my.com/tracking"
optional and one Man: "http://www.foo.com/privacy"
mandatory ...
extension
Origin server HTTP/1.1 200 OK Scope Hop-by-hop End-to-end
accepts the Ext:
mandatory Cache-Control: max-age=120, no-cache="Ext"
extension but ...
ignores the
optional one. The
client can not see
in this case that
the optional
extension was
ignored.
Table 4: Origin server with Vary header field Strength Optional Required Optional Required
(may) (must) (may) (must)
Client issues a M-GET /p/q HTTP/1.1 Mandatory Standard 501 (Not Standard 501 (Not
request with one Man: "http://www.x.y/transform"; ns=16 unsupported processing Implemented) processing Implemented)
mandatory 16-use-transform: xyzzy
extension ...
Origin server HTTP/1.1 200 OK Extension Standard 510 (Not Standard 510 (Not
accepts the Ext: unsupported processing Extended) processing Extended)
mandatory but Vary: Man Extension Extended Extended Extended Extended
indicates that the Date: Sun, 25 Oct 1998 08:12:31 GMT supported processing processing processing processing
response varies on Expires: Sun, 25 Oct 1998 08:12:31 GMT
the request Cache-Control: no-cache="Ext", max-
extension age=100000
declaration ...
15.2 User Agent to Origin Server via HTTP/1.1 Proxy Table 2: Proxy Server
These two examples show how an extended request interacts with an Scope Hop-by-hop End-to-end
HTTP/1.1 proxy.
Table 5: HTTP/1.1 Proxy forwards extended request Strength Optional Required Optional Required
(may) (must) (may) (must)
Client issues a M-GET /some-document HTTP/1.1 Mandatory Strip 501 (Not Forward 501 (Not
request with one C-Opt: "http://www.meter.org/hits" unsupported extension Implemented) extension Implemented)
optional and one C-Man: "http://www.copy.org/rights" or tunnel or tunnel
mandatory hop-by- Connection: C-Opt, C-Man
hop extension ...
HTTP/1.1 proxy M-GET /some-document HTTP/1.1 Extension Strip 510 (Not Forward Forward
forwards the Via: 1.1 new unsupported extension Extended) extension extension
request and takes ...
out the connection
headers
Origin server HTTP/1.1 510 Not Extended Extension Extended Extended Extended Extended
fails as the ... supported processing processing processing, processing,
request does not and strip and strip may strip may strip
contain any
information
belonging to the
M-GET method
Table 6: HTTP/1.1 Proxy does not forward extended request 15. Examples
Client issues a M-GET /some-document HTTP/1.1 The following examples show various scenarios using mandatory in
request with one C-Opt: "http://www.meter.org/hits" HTTP/1.1 requests and responses. Information not essential for
optional and one C-Man: "http://www.copy.org/rights" illustrating the examples is left out (referred to as "...")
mandatory hop-by- Connection: C-Opt, C-Man
hop extension ...
HTTP/1.1 proxy HTTP/1.1 501 Not Implemented 15.1 User Agent to Origin Server
refuses to forward ...
the M-GET method
and returns an
error
Origin server Table 3: User Agent directly to origin server
never sees the
extended request
15.3 User Agent to Origin Server via HTTP/1.0 Proxy Client issues a request M-GET /some-document HTTP/1.1
with one optional and Opt: "http://www.my.com/tracking"
one mandatory extension Man: "http://www.foo.com/privacy"
...
These two examples show how an extended request interacts with an Origin server accepts HTTP/1.1 200 OK
HTTP/1.0 proxy in the message path the mandatory extension Ext:
Table 7: HTTP/1.0 Proxy forwards extended request but ignores the Cache-Control: max-age=120, no-cache="Ext"
optional one. The ...
client can not see in
this case that the
optional extension was
ignored.
Client issues a M-GET /some-document HTTP/1.1 Table 4: Origin server with Vary header field
request with one Man: "http://www.price.com/sale"
mandatory ...
extension
HTTP/1.0 proxy M-GET /some-document HTTP/1.0 Client issues a request M-GET /p/q HTTP/1.1
forwards the Man: "http://www.price.com/sale" with one mandatory Man: "http://www.x.y/transform"; ns=16
request as a ... extension 16-use-transform: xyzzy
HTTP/1.0 request ...
without changing
the method
Origin server HTTP/1.1 200 OK Origin server accepts HTTP/1.1 200 OK
accepts Ext: the mandatory but Ext:
declaration and Date: Sun, 25 Oct 1998 08:12:31 GMT indicates that the Vary: Man, 16-use-transform
returns a 200 Expires: Sun, 25 Oct 1998 08:12:31 GMT response varies on the Date: Sun, 25 Oct 1998 08:12:31 GMT
response and an Cache-Control: no-cache="Ext", max-age=600 request extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
extension ... declaration Cache-Control: no-cache="Ext", max-age=1000
acknowledgement. ...
The response can
be cached by
HTTP/1.1 caches
for 10 minutes.
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain 15.2 User Agent to Origin Server via HTTP/1.1 Proxy
Client issues a M-GET /some-document HTTP/1.1 These two examples show how an extended request interacts with an
request with one Man: "http://www.copy.org/rights" HTTP/1.1 proxy.
mandatory and one C-Opt: "http://www.ads.org/noads"
hop-by-hop Connection: C-Opt
optional extension ...
HTTP/1.0 proxy M-GET /some-document HTTP/1.0 Table 5: HTTP/1.1 Proxy forwards extended request
forwards the Man: "http://www.copy.org/rights"
request as C-Opt: "http://www.ads.org/noads"
HTTP/1.0 request Connection: C-Man
without changing ...
the method and
without honoring
the Connection
header field.
HTTP/1.1 proxy M-GET /some-document HTTP/1.1 Client issues a request M-GET /some-document HTTP/1.1
deletes (and Man: "http://www.copy.org/rights" with one optional and C-Opt: "http://www.meter.org/hits"
ignores) the C-Man: "http://www.ads.org/givemeads" one mandatory hop-by- C-Man: "http://www.copy.org/rights"
optional extension Connection: C-Man hop extension Connection: C-Opt, C-Man
and forwards the Via: 1.0 new ...
rest including a ...
via header field.
It also add it's
own hop-by-hop
mandatory
extension
Origin server HTTP/1.1 200 OK HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1
accepts both Ext: the request and takes Via: 1.1 new
mandatory C-Ext out the connection ...
extensions. The Connection: C-Man headers
response is not Date: Sun, 25 Oct 1998 08:12:31 GMT
cachable by the Expires: Sun, 25 Oct 1998 08:12:31 GMT
HTTP/1.0 cache but Cache-Control: no-cache="Ext", max-age=3600
can be cached for ...
1 hour by HTTP/1.1
caches.
HTTP/1.1 proxy HTTP/1.1 200 OK Origin server fails as HTTP/1.1 510 Not Extended
removes the hop- Ext: the request does not ...
by-hop extension Date: Sun, 25 Oct 1998 08:12:31 GMT contain any information
acknowledgement Expires: Sun, 25 Oct 1998 08:12:31 GMT belonging to the M-GET
and forwards the Cache-Control: no-cache="Ext", max-age=3600 method
remainder of the ... Table 6: HTTP/1.1 Proxy does not forward extended request
response.
Client issues a request M-GET /some-document HTTP/1.1
with one optional and C-Opt: "http://www.meter.org/hits"
one mandatory hop-by- C-Man: "http://www.copy.org/rights"
hop extension Connection: C-Opt, C-Man
...
HTTP/1.1 proxy refuses HTTP/1.1 501 Not Implemented
to forward the M-GET ...
method and returns an
error
Origin server never
sees the extended
request
15.3 User Agent to Origin Server via HTTP/1.0 Proxy
These two examples show how an extended request interacts with an
HTTP/1.0 proxy in the message path
Table 7: HTTP/1.0 Proxy forwards extended request
Client issues a request M-GET /some-document HTTP/1.1
with one mandatory Man: "http://www.price.com/sale"
extension ...
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
the request as a Man: "http://www.price.com/sale"
HTTP/1.0 request ...
without changing the
method
Origin server accepts HTTP/1.1 200 OK
declaration and returns Ext:
a 200 response and an Date: Sun, 25 Oct 1998 08:12:31 GMT
extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
acknowledgement. The Cache-Control: no-cache="Ext", max-age=600
response can be cached ...
by HTTP/1.1 caches for
10 minutes.
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
Client issues request M-GET /some-document HTTP/1.1
with one mandatory and Man: "http://www.copy.org/rights"
one hop-by-hop optional C-Opt: "http://www.ads.org/noads"
extension Connection: C-Opt
...
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
request as HTTP/1.0 Man: "http://www.copy.org/rights"
request without C-Opt: "http://www.ads.org/noads"
changing the method and Connection: C-Man
without honoring the ...
Connection directives
HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights"
extension and forwards C-Man: "http://www.ads.org/givemeads"
the rest including a Connection: C-Man
via header field. It Via: 1.0 new
also add a hop-by-hop ...
mandatory extension
Origin server accepts HTTP/1.1 200 OK
both mandatory Ext:
extensions. The C-Ext
response is not Connection: C-Ext
cachable by the Date: Sun, 25 Oct 1998 08:12:31 GMT
HTTP/1.0 cache but can Expires: Sun, 25 Oct 1998 08:12:31 GMT
be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600
HTTP/1.1 caches. ...
HTTP/1.1 proxy removes HTTP/1.1 200 OK
the hop-by-hop Ext:
extension Date: Sun, 25 Oct 1998 08:12:31 GMT
acknowledgement and Expires: Sun, 25 Oct 1998 08:12:31 GMT
forwards the remainder Cache-Control: no-cache="Ext", max-age=3600
of the response. ...
 End of changes. 157 change blocks. 
632 lines changed or deleted 552 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/