summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2774.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2774.txt')
-rw-r--r--doc/rfc/rfc2774.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc2774.txt b/doc/rfc/rfc2774.txt
new file mode 100644
index 0000000..cb8328a
--- /dev/null
+++ b/doc/rfc/rfc2774.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group H. Nielsen
+Request for Comments: 2774 P. Leach
+Category: Experimental Microsoft
+ S. Lawrence
+ Agranat Systems
+ February 2000
+
+
+ An HTTP Extension Framework
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+IESG Note
+
+ This document was originally requested for Proposed Standard status.
+ However, due to mixed reviews during Last Call and within the HTTP
+ working group, it is being published as an Experimental document.
+ This is not necessarily an indication of technical flaws in the
+ document; rather, there is a more general concern about whether this
+ document actually represents community consensus regarding the
+ evolution of HTTP. Additional study and discussion are needed before
+ this can be determined.
+
+ Note also that when HTTP is used as a substrate for other protocols,
+ it may be necessary or appropriate to use other extension mechanisms
+ in addition to, or instead of, those defined here. This document
+ should therefore not be taken as a blueprint for adding extensions to
+ HTTP, but it defines mechanisms that might be useful in such
+ circumstances.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 1]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+Abstract
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction ...............................................3
+ 2. Notational Conventions .....................................3
+ 3. Extension Declarations .....................................4
+ 3.1 Header Field Prefixes ...................................5
+ 4. Extension Header Fields ....................................6
+ 4.1 End-to-End Extensions ...................................7
+ 4.2 Hop-by-Hop Extensions ...................................7
+ 4.3 Extension Response Header Fields ........................8
+ 5. Mandatory HTTP Requests ....................................8
+ 5.1 Fulfilling a Mandatory Request .........................10
+ 6. Mandatory HTTP Responses ..................................11
+ 7. 510 Not Extended ..........................................11
+ 8. Publishing an Extension ...................................11
+ 9. Caching Considerations ....................................12
+ 10. Security Considerations ...................................13
+ 11. References ................................................13
+ 12. Acknowledgements ..........................................14
+ 13. Authors' Addresses ........................................14
+ 14. Summary of Protocol Interactions ..........................15
+ 15. Examples ..................................................16
+ 15.1 User Agent to Origin Server ............................16
+ 15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........17
+ 15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........18
+ Full Copyright Statement ......................................20
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 2]
+
+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 [Page 3]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ 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].
+
+ This proposal does not rely on particular features defined in URLs
+ [8] that cannot potentially be expressed using URNs (see section 8).
+ Therefore, the more generic term URI [8] is used throughout the
+ specification.
+
+3. Extension Declarations
+
+ An extension declaration can be used to indicate that an extension
+ has 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
+ extension to a message nor whether two extensions can or cannot
+ logically coexist within the same message. It is simply a framework
+ 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 grammar for an extension declaration is as follows:
+
+ ext-decl = <"> ( absoluteURI | field-name ) <">
+ [ namespace ] [ decl-extensions ]
+
+ namespace = ";" "ns" "=" header-prefix
+ header-prefix = 2*DIGIT
+
+ decl-extensions = *( decl-ext )
+ decl-ext = ";" token [ "=" ( token | quoted-string ) ]
+
+ 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 support for header field names as extension identifiers provides
+ a 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.
+
+
+
+
+
+Nielsen, et al. Experimental [Page 4]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ Examples of extension declarations are
+
+ "http://www.company.com/extension"; ns=11
+ "Range"
+
+ An agent MAY use the decl-extensions mechanism to include optional
+ extension declaration parameters but cannot assume these parameters
+ to 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
+
+ The header-prefix is a dynamically generated string. All header
+ fields in the message that match this string, using string prefix-
+ matching, belong to that extension declaration. Header field prefixes
+ allow an 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.
+
+ Header fields using a header-prefix are of the form:
+
+ prefixed-header = prefix-match field-name
+ prefix-match = header-prefix "-"
+
+ 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
+ ("-") 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.
+
+ Agents MUST NOT reuse header-prefix values in the same message unless
+ 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-
+ prefix values as this facilitates use of the Vary header field in
+ responses that vary as a function of the request extension
+ declaration(s) (see [5], section 13.6).
+
+
+
+Nielsen, et al. Experimental [Page 5]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ Servers including prefixed-header header fields in a Vary header
+ field value MUST also include the corresponding extension declaration
+ field-name as part of that value. For example, if a response depends
+ on the value of the 16-use-transform header field defined by an
+ optional extension declaration in the request, the Vary header field
+ in the response could look like this:
+
+ Vary: Opt, 16-use-transform
+
+ Note, that header-prefix consistency is no substitute for including
+ an extension declaration in the message: header fields with header-
+ prefix values not defined by an extension declaration in the same
+ message are not defined by this specification.
+
+ Examples of header-prefix values are
+
+ 12
+ 15
+ 23
+
+ Old applications may introduce header fields independent of this
+ extension mechanism, potentially conflicting with header fields
+ introduced by the prefix mechanism. In order to minimize this risk,
+ prefixes MUST contain at least 2 digits.
+
+4. Extension Header Fields
+
+ 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).
+
+ A mandatory extension declaration indicates that the ultimate
+ recipient MUST consult and adhere to the rules given by the extension
+ when processing the message or reporting an error (see section 5 and
+ 7).
+
+ An optional extension declaration indicates that the ultimate
+ recipient of the extension MAY consult and adhere to the rules given
+ 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.
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 6]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ 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.)
+
+ The header fields are general header fields as they describe which
+ extensions actually are applied to an HTTP message. Optional
+ declarations MAY be applied to any HTTP message if appropriate (see
+ section 5 for how to apply mandatory extension declarations to
+ requests and section 6 for how to apply them to responses).
+
+4.1 End-to-End Extensions
+
+ End-to-end declarations MUST be transmitted to the ultimate recipient
+ of the declaration. The Man and the Opt general header fields are
+ end- to-end header fields and are defined as follows:
+
+ mandatory = "Man" ":" 1#ext-decl
+ optional = "Opt" ":" 1#ext-decl
+
+ For example
+
+ HTTP/1.1 200 OK
+ Content-Length: 421
+ Opt: "http://www.digest.org/Digest"; ns=15
+ 15-digest: "snfksjgor2tsajkt52"
+ ...
+
+ The ultimate recipient of a mandatory end-to-end extension
+ declaration MUST handle that extension declaration as described in
+ section 5 and 6.
+
+4.2 Hop-by-Hop Extensions
+
+ Hop-by-hop extension declarations are meaningful only for a single
+ 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-mandatory = "C-Man" ":" 1#ext-decl
+ c-optional = "C-Opt" ":" 1#ext-decl
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 7]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ For example
+
+ M-GET / HTTP/1.1
+ Host: some.host
+ C-Man: "http://www.digest.org/ProxyAuth"; ns=14
+ 14-Credentials="g5gj262jdw@4df"
+ Connection: C-Man, 14-Credentials
+
+ The ultimate recipient of a mandatory hop-by-hop extension
+ declaration MUST handle that extension declaration as described in
+ section 5 and 6.
+
+4.3 Extension Response Header Fields
+
+ Two extension response header fields are used to indicate that a
+ request containing mandatory extension declarations has been
+ fulfilled by the ultimate recipient as described in section 5.1. The
+ extension response header fields are exclusively intended to serve as
+ extension acknowledgements, and can not carry any other information.
+
+ The Ext header field is used to indicate that all end-to-end
+ mandatory extension declarations in the request were fulfilled:
+
+ ext = "Ext" ":"
+
+ The C-Ext response header field is used to indicate that all hop-by-
+ hop mandatory extension declarations in the request were fulfilled.
+
+ c-ext = "C-Ext" ":"
+
+ In HTTP/1.1, the C-Ext header fields MUST be protected by a
+ Connection header (see [5], section 14.10).
+
+ The Ext and the C-Ext header fields are not mutually exclusive; they
+ can both occur within the same message as described in section 5.1.
+
+5. Mandatory HTTP Requests
+
+ 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:
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 8]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ M-PUT /a-resource HTTP/1.1
+ Man: "http://www.copyright.org/rights-management"; ns=16
+ 16-copyright: http://www.copyright.org/COPYRIGHT.html
+ 16-contributions: http://www.copyright.org/PATCHES.html
+ Host: www.w3.org
+ Content-Length: 1203
+ Content-Type: text/html
+
+ <!doctype html ...
+
+ An ultimate recipient conforming to this specification receiving a
+ 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
+ and end-to-end); the server MAY ignore optional declarations
+ 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
+ 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.
+
+ 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
+ extension declaration MUST NOT remove the extension declaration or
+ the "M-" method name prefix when forwarding the message (see section
+ 5.1 for how to detect when a mandatory extension has been fulfilled).
+
+ 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 receiving a mandatory request including the "M-" method name
+ prefix without any mandatory extension declarations to follow MUST
+ return a 510 (Not Extended) response.
+
+
+
+
+Nielsen, et al. Experimental [Page 9]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ The "M-" prefix is reserved by this proposal and MUST NOT be used by
+ other HTTP extensions.
+
+5.1 Fulfilling a Mandatory Request
+
+ A server MUST NOT claim to have fulfilled any mandatory request
+ unless it understood and obeyed all the mandatory extension
+ declarations in the request. This section defines a mechanism for
+ conveying this 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 any end-to-end mandatory extension declarations were among the
+ 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
+ Ext:
+ Cache-Control: no-cache="Ext"
+ ...
+
+ If the mandatory request has been forwarded by an HTTP/1.0
+ intermediary proxy then this is indicated either directly in the
+ Request-Line or by the presence of an HTTP/1.1 Via header field. In
+ 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 (see
+ section 9 for a discussion on caching considerations):
+
+ HTTP/1.1 200 OK
+ Date: Sun, 25 Oct 1998 08:12:31 GMT
+ Expires: Sun, 25 Oct 1998 08:12:31 GMT
+ Ext:
+ Cache-Control: no-cache="Ext", max-age=3600
+ ...
+
+ If any hop-by-hop mandatory extension declarations were among the
+ fulfilled extensions then the server MUST include a C-Ext response
+ header field in the response. The C-Ext header field MUST be
+ protected by a Connection header field (see [5], section 14.10).
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 10]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ HTTP/1.1 200 OK
+ C-Ext:
+ Connection: C-Ext
+
+ Note, that the Ext and C-Ext header fields are not mutually
+ exclusive; 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 MUST NOT include mandatory extension declarations in an HTTP
+ response unless it is responding to a mandatory HTTP request whose
+ definition allowed for the mandatory response or the server has some
+ a 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
+ 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.
+
+7. 510 Not Extended
+
+ The policy for accessing the resource has not been met in the
+ request. The server should send back all the information necessary
+ for the client to issue an extended request. It is outside the scope
+ of this specification to specify how the extensions inform the
+ client.
+
+ 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.
+
+8. Publishing an Extension
+
+ 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.
+
+
+
+
+Nielsen, et al. Experimental [Page 11]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ Likewise, applications are not required to attempt resolving
+ extension identifiers included in an extension declaration. The only
+ absolute requirement is that an application MUST NOT claim
+ conformance with an extension that it does not recognize (regardless
+ of whether it has tried to resolve the extension identifier or not).
+ This document does 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 might be made by distributing a specification, which
+ references the extension identifier.
+
+ It is strongly recommended that the integrity and persistence of the
+ extension identifier be maintained and kept unquestioned throughout
+ the lifetime of the extension. Care should be taken not to distribute
+ 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 extension definition may be made available in different
+ representations ranging from
+
+ o a human-readable specification defining the extension semantics
+ (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
+ 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.
+
+9. Caching Considerations
+
+ Use of extensions using the syntax defined by this document may have
+ additional implications on the cachability of HTTP response messages
+ other than the ones described in section 5.1.
+
+
+
+Nielsen, et al. Experimental [Page 12]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ 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.
+
+10. Security Considerations
+
+ Dynamic installation of extension facilities as described in the
+ 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
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [2] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
+ Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+ [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996.
+
+ [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [7] Masinter, L., "Hyper Text Coffee Pot Control Protocol
+ (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+ [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+
+
+
+
+Nielsen, et al. Experimental [Page 13]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ [9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension
+ mechanism for HTTP", Work in Progress.
+
+12. Acknowledgements
+
+ 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].
+
+ The contribution of World Wide Web Consortium (W3C) staff is part of
+ the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity").
+
+13. Authors' Addresses
+
+ Henrik Frystyk Nielsen
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052, USA
+
+ EMail: frystyk@microsoft.com
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052, USA
+
+ EMail: paulle@microsoft.com
+
+
+ Scott Lawrence
+ Agranat Systems, Inc.
+ 5 Clocktower Place, Suite 400
+ Maynard, MA 01754, USA
+
+ EMail: lawrence@agranat.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 14]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+Appendices
+
+14. Summary of Protocol Interactions
+
+ 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.
+
+ Table 1: Origin Server
+
+ Scope Hop-by-hop End-to-end
+
+ Strength Optional Required Optional Required
+ (may) (must) (may) (must)
+
+ Mandatory Standard 501 (Not Standard 501 (Not
+ unsupported processing Implemented) processing Implemented)
+
+ Extension Standard 510 (Not Standard 510 (Not
+ unsupported processing Extended) processing Extended)
+ Extension Extended Extended Extended Extended
+ supported processing processing processing processing
+
+
+ Table 2: Proxy Server
+
+ Scope Hop-by-hop End-to-end
+
+ Strength Optional Required Optional Required
+ (may) (must) (may) (must)
+
+ Mandatory Strip 501 (Not Forward 501 (Not
+ unsupported extension Implemented) extension Implemented)
+ or tunnel or tunnel
+
+ Extension Strip 510 (Not Forward Forward
+ unsupported extension Extended) extension extension
+
+ Extension Extended Extended Extended Extended
+ supported processing processing processing, processing,
+ and strip and strip may strip may strip
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 15]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+15. Examples
+
+ The following examples show various scenarios using mandatory in
+ 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
+
+ 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"
+ ...
+
+ Origin server accepts HTTP/1.1 200 OK
+ the mandatory extension Ext:
+ 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.
+
+
+ Table 4: Origin server with Vary header field
+
+ Client issues a request M-GET /p/q HTTP/1.1
+ with one mandatory Man: "http://www.x.y/transform"; ns=16
+ extension 16-use-transform: xyzzy
+ ...
+
+ Origin server accepts HTTP/1.1 200 OK
+ the mandatory but Ext:
+ indicates that the Vary: Man, 16-use-transform
+ response varies on the Date: Sun, 25 Oct 1998 08:12:31 GMT
+ request extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
+ declaration Cache-Control: no-cache="Ext", max-age=1000
+ ...
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 16]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+15.2 User Agent to Origin Server via HTTP/1.1 Proxy
+
+ These two examples show how an extended request interacts with an
+ HTTP/1.1 proxy.
+
+ Table 5: HTTP/1.1 Proxy forwards extended request
+
+ 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 forwards M-GET /some-document HTTP/1.1
+ the request and takes Via: 1.1 new
+ out the connection ...
+ headers
+
+ Origin server fails as HTTP/1.1 510 Not Extended
+ the request does not ...
+ contain any information
+ belonging to the M-GET
+ method
+
+ Table 6: HTTP/1.1 Proxy does not forward extended request
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 17]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+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
+
+
+
+Nielsen, et al. Experimental [Page 18]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+ 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. ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 19]
+
+RFC 2774 An HTTP Extension Framework February 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al. Experimental [Page 20]
+