RFC2774 日本語訳
2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT=39719 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Nielsen
Request for Comments: 2774 P. Leach
Category: Experimental Microsoft
S. Lawrence
Agranat Systems
February 2000
Network Working Group H. Nielsen Request for Comments: 2774 P. Leach Category: Experimental Microsoft S. Lawrence Agranat Systems February 2000
An HTTP Extension Framework
An HTTP Extension Framework
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
IESG Note
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.
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.
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
Nielsen, et al. Experimental [Page 1] RFC 2774 An HTTP Extension Framework February 2000
Abstract
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.
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
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
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
Nielsen, et al. Experimental [Page 2] RFC 2774 An HTTP Extension Framework February 2000
1. Introduction
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:
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 extending a single HTTP message;
o introducing new encodings;
o introducing new encodings;
o initiating HTTP-derived protocols for new applications; to...
o initiating HTTP-derived protocols for new applications; to...
o switching to protocols which, once initiated, run independent
of the original protocol stack.
o switching to protocols which, once initiated, run independent of the original protocol stack.
The proposal is intended to be used as follows:
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 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 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.
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).
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
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].
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
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].
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.
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
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.
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.
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:
The grammar for an extension declaration is as follows:
ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]
ext-decl = <"> ( absoluteURI | field-name ) <"> [ namespace ] [ decl-extensions ]
namespace = ";" "ns" "=" header-prefix
header-prefix = 2*DIGIT
namespace = ";" "ns" "=" header-prefix header-prefix = 2*DIGIT
decl-extensions = *( decl-ext )
decl-ext = ";" token [ "=" ( token | quoted-string ) ]
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 (":").
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.
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
Nielsen, et al. Experimental [Page 4] RFC 2774 An HTTP Extension Framework February 2000
Examples of extension declarations are
Examples of extension declarations are
"http://www.company.com/extension"; ns=11
"Range"
"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.
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
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.
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:
Header fields using a header-prefix are of the form:
prefixed-header = prefix-match field-name
prefix-match = header-prefix "-"
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.
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.
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).
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).
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
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:
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
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.
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
Examples of header-prefix values are
12
15
23
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.
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
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).
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).
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.
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
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 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).
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
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:
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
mandatory = "Man" ":" 1#ext-decl optional = "Opt" ":" 1#ext-decl
For example
For example
HTTP/1.1 200 OK
Content-Length: 421
Opt: "http://www.digest.org/Digest"; ns=15
15-digest: "snfksjgor2tsajkt52"
...
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.
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
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:
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
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
Nielsen, et al. Experimental [Page 7] RFC 2774 An HTTP Extension Framework February 2000
For example
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
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.
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
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.
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:
The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled:
ext = "Ext" ":"
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.
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" ":"
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).
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.
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
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:
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
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
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 ...
<!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:
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;
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);
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.
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.
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 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 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.
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
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.
The "M-" prefix is reserved by this proposal and MUST NOT be used by other HTTP extensions.
5.1 Fulfilling a Mandatory Request
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.
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:
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"
...
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):
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
...
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).
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
Nielsen, et al. Experimental [Page 10] RFC 2774 An HTTP Extension Framework February 2000
HTTP/1.1 200 OK
C-Ext:
Connection: C-Ext
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.
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
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).
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.
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
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.
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.
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
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.
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
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.
拡大識別子の保全と固執が維持されて、拡大の生涯の間中疑いがなく保たれることが強く勧められます。 同じ名前に参照をつける闘争仕様を分配しないように注意するべきです。 ファイル拡張仕様書をURIのアドレスで利用可能にするときさえ、注意しなければなりません。そのアドレスで利用可能にされた仕様は時間がたつにつれて、変化しません。 1人のエージェントが古い意味論に識別子を関連づけるかもしれませんが、別のものは新しい意味論にそれを関連づけるかもしれません。
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 拡大意味論を定義する人間読み込み可能な仕様、(例えば、[7])を見てください。
o downloadable code which implements the semantics defined by the
extension,
o 拡大で定義された意味論を実装するダウンローダブルなコード
o a formal interface description provided by the extension, to
o 拡大で提供された、正式なインタフェース記述
o a machine-readable specification defining the extension
semantics.
o 拡大意味論を定義する機械可読な仕様。
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
9. 問題をキャッシュします。
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.
このドキュメントによって定義された構文を使用する拡張子の使用はセクション5.1で説明されたもの以外のHTTP応答メッセージのcachabilityに追加意味を持っているかもしれません。
Nielsen, et al. Experimental [Page 12] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[12ページ]RFC2774
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.
拡張メッセージの創始者は、拡大の意味論から拡大の存在が応答メッセージのキャッシュ規制に影響を与えるかどうか決定できるべきです。 拡張子が応答のcachebilityで、よりきつい規制を必要とするなら、創始者は必要なレベルの敷衍された意味論の規制に対応するキャッシュヘッダーフィールド(キャッシュコントロール、Vary、Expires)の適切な組み合わせを入れなければなりません。
10. Security Considerations
10. セキュリティ問題
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.
序論の説明されるとしての拡大能力のダイナミックなインストールは別のもの(ホストソフトウェアを運用しているパーティー)の権威の下で実行されるために1回のパーティー(実装のプロバイダー)によって書かれたソフトウェアにかかわります。 これはプロバイダーによるさまざまな「トロイの木馬」攻撃へのホストパーティー、またはプロバイダーの名前の下で実装を鍛造する悪意がある第三者を開きます。 RFC2046[4]、見てください、そして、例えば、これらの議論のための.2が危険にさらす4.5を区分してください。
11. References
11. 参照
[1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[2] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[2]バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[5] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, 1 April 1998.
[7]Masinter、L.、「超-テキストコーヒーポット制御プロトコル(HTCPCP/1.0)」、RFC2324 1998年4月1日。
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
Nielsen, et al. Experimental [Page 13] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[13ページ]RFC2774
[9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension
mechanism for HTTP", Work in Progress.
[9] ニールセン、H.、コノリー、D.、およびR.Khare、「PEP--、HTTPのための拡張機能、」、ProgressのWork。
12. Acknowledgements
12. 承認
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].
ロイFielding(Rohit Khare、ヤロンY.Goland、およびクンHoltman)はこの仕様のすべてのフェーズでコメントする際にそれらの取り組みのための特別な認識に値します。 また、ジョッシュ・コーエン、ロス・パターソン、ジムGettys、ラリーMasinterと、そして、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").
ワールドワイドウェブコンソーシアム(W3C)のスタッフの貢献はW3C HTTP Activityの一部(" http://www.w3.org/Protocols/Activity "を見る)です。
13. Authors' Addresses
13. 作者のアドレス
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Henrik Frystykニールセンマイクロソフト社1マイクロソフト道、ワシントン 98052、レッドモンド(米国)
EMail: frystyk@microsoft.com
メール: frystyk@microsoft.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
ポールJ.リーチマイクロソフト社1マイクロソフト道、ワシントン 98052、レッドモンド(米国)
EMail: paulle@microsoft.com
メール: paulle@microsoft.com
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
Inc.5Clocktowerが置くスコットローレンスAgranat Systems、Suite400メイナード、MA 01754、米国
EMail: lawrence@agranat.com
メール: lawrence@agranat.com
Nielsen, et al. Experimental [Page 14] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[14ページ]RFC2774
Appendices
付録
14. Summary of Protocol Interactions
14. プロトコル相互作用の概要
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.
以下のテーブルは強さの結果、言いなりになっていて不従順なHTTPプロキシと発生源サーバの義務的な提案の範囲規則をまとめます。 概要は、ガイドとインデックスとしてテキストに意図しますが、必ず不可解であって、不完全です。 この概要は、別々に完全な仕様から使用されるべきではありませんし、決して参照をつけられるべきではありません。
Table 1: Origin Server
テーブル1: 発生源サーバ
Scope Hop-by-hop End-to-end
範囲の終わりからホップごとのエンド
Strength Optional Required Optional Required
(may) (must) (may) (must)
強さの任意の必要な任意の必要な(may) (must) (may)(must)
Mandatory Standard 501 (Not Standard 501 (Not unsupported processing Implemented) processing Implemented)
強制基準501(Standard501(サポートされない処理Implementedでない)処理Implementedでない)
Extension Standard 510 (Not Standard 510 (Not unsupported processing Extended) processing Extended) Extension Extended Extended Extended Extended supported processing processing processing processing
処理処理処理処理であるとサポートされた拡大Standard510(Standard510(サポートされない処理Extendedでない)処理Extendedでない)拡大Extended Extended Extended Extended
Table 2: Proxy Server
テーブル2: Proxyサーバ
Scope Hop-by-hop End-to-end
範囲の終わりからホップごとのエンド
Strength Optional Required Optional Required
(may) (must) (may) (must)
強さの任意の必要な任意の必要な(may) (must) (may)(must)
Mandatory Strip 501 (Not Forward 501 (Not
unsupported extension Implemented) extension Implemented)
or tunnel or tunnel
義務的なStrip501(Forward501(サポートされない拡大Implementedでない)拡張子Implementedでない)、トンネルまたはトンネル
Extension Strip 510 (Not Forward Forward unsupported extension Extended) extension extension
拡大Strip510(Forward Forwardのサポートされない拡張子Extendedでない)拡大拡張子
Extension Extended Extended Extended Extended
supported processing processing processing, processing,
and strip and strip may strip may strip
処理、処理、片、および片が剥取るかもしれない処理処理であるとサポートされた拡大Extended Extended Extended Extendedは剥取るかもしれません。
Nielsen, et al. Experimental [Page 15] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[15ページ]RFC2774
15. Examples
15. 例
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 "...")
以下の例は、HTTP/1.1の要求と応答で義務的な状態で使用することで様々なシナリオを示しています。 例を例証するには、不可欠でない情報は省かれます。「(」 …と呼ばれる、」、)
15.1 User Agent to Origin Server
15.1 発生源サーバへのユーザエージェント
Table 3: User Agent directly to origin server
テーブル3: 直接発生源サーバへのユーザエージェント
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"
...
クライアントが要求M-GET/を発行する、いくつか、-、ドキュメント、1つが任意のHTTP/1.1とOpt: " http://www.my.com/tracking "1義務的な拡大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.
発生源サーバはHTTP/1.1 200にOK義務的な拡大Extを受け入れます: しかし、Cache-コントロールを無視します: 最大時代は120、キャッシュがないことの="Ext"任意の1つと等しいです。 …クライアントは、この場合任意の拡大が無視されたのを見ることができません。
Table 4: Origin server with Vary header field
テーブル4: Varyヘッダーフィールドがある発生源サーバ
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
...
クライアントは1義務的なManと共に要求M-GET/p/qにHTTP/1.1を発行します: " http://www.x.y/transform "。 16が変換を使用していた状態で、ナノ秒は16拡大と等しいです: 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
...
発生源サーバはHTTP/1.1 200にOK義務的Extだけを受け入れます: それを示す、Vary: やれやれ、16が変換を使用している応答は日付:で異なります。 グリニッジ標準時1998年10月25日日曜日8時12分31秒の要求拡張子Expires: グリニッジ標準時1998年10月25日日曜日8時12分31秒の宣言Cache-コントロール: ="Ext"、最大時代=1000をキャッシュしないでください…
Nielsen, et al. Experimental [Page 16] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[16ページ]RFC2774
15.2 User Agent to Origin Server via HTTP/1.1 Proxy
15.2 HTTP/1.1Proxyを通したOrigin Serverのユーザエージェント
These two examples show how an extended request interacts with an HTTP/1.1 proxy.
これらの2つの例が拡張要求がどうHTTP/1.1プロキシと対話するかを示しています。
Table 5: HTTP/1.1 Proxy forwards extended request
テーブル5: HTTP/1.1のProxyフォワードが要求を広げました。
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
...
クライアントが要求M-GET/を発行する、いくつか、-、ドキュメント、1つが任意でCで選んでいるHTTP/1.1: " http://www.meter.org/hits "の1人の近く義務的な跳びC-男性: " http://www.copy.org/rights "ホップ拡大Connection: C-男性はCで選んでください…
HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1 the request and takes Via: 1.1 new out the connection ... headers
HTTP/1.1プロキシがM-GET/を進める、いくつか、-、ドキュメント、HTTP/1.1、要求と撮影、Via: 1.1の新しいアウトは接続…ヘッダーです。
Origin server fails as HTTP/1.1 510 Not Extended the request does not ... contain any information belonging to the M-GET method
要求がするHTTP/1.1 510Not ExtendedがM-GETメソッドに属す少しの情報も含まないとき、…発生源サーバは失敗します。
Table 6: HTTP/1.1 Proxy does not forward extended request
テーブル6: HTTP/1.1Proxyは拡張要求を転送しません。
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
...
クライアントが要求M-GET/を発行する、いくつか、-、ドキュメント、1つが任意でCで選んでいるHTTP/1.1: " http://www.meter.org/hits "の1人の近く義務的な跳びC-男性: " http://www.copy.org/rights "ホップ拡大Connection: C-男性はCで選んでください…
HTTP/1.1 proxy refuses HTTP/1.1 501 Not Implemented to forward the M-GET ... method and returns an error
HTTP/1.1プロキシは、M-GET…メソッドを進めるためにHTTP/1.1 501Not Implementedを拒否して、誤りを返します。
Origin server never sees the extended request
発生源サーバは拡張要求を決して見ません。
Nielsen, et al. Experimental [Page 17] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[17ページ]RFC2774
15.3 User Agent to Origin Server via HTTP/1.0 Proxy
15.3 HTTP/1.0Proxyを通したOrigin Serverのユーザエージェント
These two examples show how an extended request interacts with an HTTP/1.0 proxy in the message path
これらの2つの例が拡張要求がメッセージ経路でどうHTTP/1.0プロキシと対話するかを示しています。
Table 7: HTTP/1.0 Proxy forwards extended request
テーブル7: HTTP/1.0のProxyフォワードが要求を広げました。
Client issues a request M-GET /some-document HTTP/1.1 with one mandatory Man: "http://www.price.com/sale" extension ...
クライアントが要求M-GET/を発行する、いくつか、-、ドキュメント、1義務的なManがあるHTTP/1.1: " http://www.price.com/sale "拡大…
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
HTTP/1.0プロキシがM-GET/を進める、いくつか、-、ドキュメント、HTTP/、1.0 Manとしての要求: メソッドを変えることのないHTTP/1.0が要求する" http://www.price.com/sale "
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.
発生源サーバは、HTTP/1.1 200OK宣言を受け入れて、Extを返します: 200応答と日付: グリニッジ標準時1998年10月25日日曜日8時12分31秒の延期Expires: グリニッジ標準時1998年10月25日日曜日8時12分31秒の承認。 キャッシュ制御: 600キャッシュがない="Ext"、最大時代=応答をキャッシュできます… 10分間のHTTP/1.1のキャッシュで。
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
テーブル8: HTTP/1.0とHTTP/1.1プロキシチェーン
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
...
クライアント問題がM-GET/を要求する、いくつか、-、ドキュメント、1つが義務的のHTTP/1.1とMan: ホップによるワンバウンドの" http://www.copy.org/rights "、任意である、Cで選んでください: " http://www.ads.org/noads "拡大Connection: Cで選んでください…
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.0プロキシがM-GET/を進める、いくつか、-、ドキュメント、HTTP/1.0はHTTP/1.0としてManを要求します: Cで選ぶことのない" http://www.copy.org/rights "要求: メソッドを変える" http://www.ads.org/noads "とConnection: 名誉のないC-男性、… 接続指示
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
HTTP/1.1プロキシがM-GET/を削除する、いくつか、-、ドキュメント、HTTP/1.1、(無視、)、任意のMan: " http://www.copy.org/rights "拡大とフォワードC-男性: 「 http://www.ads.org/givemeads 、」 Connectionを含む残り: ヘッダーフィールドを通したC-男性。 それ、以下を通って 1.0、また、新しく、ホップごとの…義務的な拡大を加えてください。
Nielsen, et al. Experimental [Page 18] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[18ページ]RFC2774
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 200のOKのともに義務的なExtを受け入れます: 拡大。 C-Ext応答はConnectionではありません: 日付:によるC-Ext cachable グリニッジ標準時1998年10月25日日曜日8時12分31秒のHTTP/1.0キャッシュにもかかわらず、缶のExpires: グリニッジ標準時1998年10月25日日曜日8時12分31秒、1時間、Cache-コントロールで、キャッシュされてください: ="Ext"、最大時代=3600HTTP/1.1キャッシュをキャッシュしないでください。 ...
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. ...
プロキシがHTTP/1.1 200に取り除くHTTP/1.1はホップごとのExtを承認します: 拡大日付: グリニッジ標準時1998年10月25日日曜日8時12分31秒の承認とExpires: グリニッジ標準時1998年10月25日日曜日8時12分31秒は残りCache-コントロールを進めます: 3600の="Ext"、最大時代=応答をキャッシュしないでください。 ...
Nielsen, et al. Experimental [Page 19] RFC 2774 An HTTP Extension Framework February 2000
ニールセン、他 HTTP拡大フレームワーク2000年2月あたり実験的な[19ページ]RFC2774
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nielsen, et al. Experimental [Page 20]
ニールセン、他 実験的[20ページ]
一覧
スポンサーリンク
