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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
IESG Note
IESG注意
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.
この文書は、もともとのProposed Standard状態のために要求されました。しかし、ラストコール中およびHTTPワーキンググループ内で混合された検討のために、それは実験的文書として公開されています。これは、必ずしも文書の技術的欠陥を示すものではありません。むしろ、この文書は、実際にHTTPの進化に関するコミュニティのコンセンサスを表しているかどうかについて、より一般的な懸念があります。これを決定することができる前に、追加の研究と議論が必要とされています。
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.
注また、HTTPは、他のプロトコルのための基質として使用される場合、それに加えて、他の拡張メカニズムを使用することが必要または適切であり得ること、または代わりに、ここで定義されたもの。この文書は、したがって、HTTPへの拡張機能を追加するための青写真として解釈されるべきではないが、それはこのような状況において有用であるかもしれないメカニズムを定義します。
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.
アプリケーションの広い範囲がHTTPプロトコルの様々な拡張を提案しました。現在の努力は、分散オーサリング、コラボレーション、印刷、およびリモート・プロシージャ・コール機構を含む膨大な範囲に及びます。標準的な拡張を定義するためのフレームワークので、関心事の分離がなかったため、これらのHTTPの拡張機能は、調整されていません。この文書では、民間の契約と公開された仕様の間の緊張に対処すると、HTTPクライアント、サーバ、およびプロキシを使用したアプリケーションの拡張に対応するように設計されたHTTP、のための一般的な拡張メカニズムを説明しています。提案は、グローバル一意識別子と各拡張を関連付け、拡張通信に関与する当事者間の拡張識別子および関連情報を搬送するためにHTTPヘッダフィールドを使用します。
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
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:
この提案は、民間契約と公開された仕様の間の緊張に対処するために設計されています。およびソフトウェアコンポーネントによってHTTPクライアントとサーバの動的な拡張に対応するため。の範囲を導入することのできる拡張の種類：
o extending a single HTTP message;
単一のHTTPメッセージを拡張O。
o introducing new encodings;
新しいエンコーディングを導入し、O。
o initiating HTTP-derived protocols for new applications; to...
新しいアプリケーションのためのHTTP由来のプロトコルを開始し、O。に...
o switching to protocols which, once initiated, run independent of the original protocol stack.
一度開始、プロトコルに切り替えるO、元のプロトコルスタックとは独立して実行します。
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と拡張子を指定します。当事者が延長グローバルに一意のURI割り当て、そのアドレスで利用できる拡張機能の一の以上の表現を作る（セクション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（以下、エージェントと呼ばれる）は、この拡張メカニズムを実装するHTTPクライアントまたはサーバがHTTPメッセージ内の拡張宣言にそのURIを参照することによって拡張の使用を宣言し（セクション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拡張宣言が意図されている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).
提案は、HTTP / 1.1の機能を使用していますが、既存のHTTPアプリケーションと共存できるアプリケーションを拡張し、このような方法で、HTTP / 1.0のアプリケーションと互換性があります。この提案を実装するアプリケーションは、HTTP / 1.1（またはHTTPのそれ以降のバージョン）に基づいていなければなりません。
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].
この仕様は、RFC 2068と同じ表記規則および基本的な解析構築物を使用した[5]。特に、BNFは、「トークン」構築物、「引用符で囲まれた文字列」、「リクエスト行」、「フィールド名」、および本文書における「absoluteURIでは、」RFC 2068に記載されているように解釈されるべきである[5]。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
この提案は、[8]、潜在的に（セクション8を参照）のURNを使用して表現することができないURLで定義された特定の特徴に依存していません。したがって、より一般的な用語URI [8]本明細書を通して使用されます。
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.
拡張宣言は、拡張がメッセージに適用されていると、おそらく（3.1を参照）ヘッダフィールド接頭辞によって識別されるヘッダのネームスペースの一部を予約することを示すために使用することができます。このセクションでは、拡張宣言自体を定義します。セクション4は、拡張宣言を使用して、ヘッダフィールドのセットを定義します。
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.
この仕様は、メッセージにも2つの拡張ができるか、論理的に同じメッセージの中に共存させることはできませんか拡張を適用する任意の波及効果を定義していません。これは、拡張子が適用され、どのような最終的な受信者のいずれか必須または適切にそのメッセージ内の任意の拡張宣言を解釈するために行うことができますされているだけで記述するためのフレームワークです。
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
名前空間= ";" 「NS」「=」ヘッダプレフィックスヘッダ接頭= 2 * DIGIT
decl-extensions = *( decl-ext ) decl-ext = ";" token [ "=" ( token | quoted-string ) ]
供述-拡張子= *（供述-EXT）供述-EXT = ";"トークン[ "="（トークン|引用符で囲まれた文字列）]
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 (":").
延長は絶対、グローバルに一意のURIまたはフィールド名によって識別されます。フィールド名は、一意IETF標準化過程RFC [3]で定義されたヘッダフィールドを指定しなければなりません。 URIは明確にコロン（「：」）の存在によってフィールド名と区別することができます。
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.
拡張識別子としてヘッダフィールド名のサポートはに記載のガイドラインに従って定義されているIETF標準化過程のRFCに定義されたグローバルに一意なURI空間と機能との間のマッピングまで、IETF標準化過程のRFCによって定義された拡張機能の分散型の拡張から移行戦略を提供しますセクション8。
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を参照）を使用して渡すことができる拡張インスタンスデータを渡すために赤緯・エクステンションを使用してはいけません。認識されない赤緯-EXTパラメータは無視され、拡張宣言を転送するとき、プロキシによって除去してはなりません。
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.
またはプレフィックスマッチとフィールド名との間に - 線形空白（LWS）はヘッダプレフィックスとダッシュ（「」）の間に使用してはいけません。文字列プレフィックスマッチングアルゴリズムは、プレフィックス一致文字列に適用されます。
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.
数字の組み合わせとダッシュ（「 - 」）を使用して、接頭辞のフォーマットには拡張宣言は、全体のヘッダーフィールド名スペースを確保できないことを保証します。ヘッダ・プレフィックス機構は、ベースのヘッダがあり、したがって、既存のHTTP機能を備えた新しい拡張の容易な統合を可能にするための拡張インスタンス・パラメータを交換するための他のソリューションよりも好まれました。
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).
明示的に拡張（拡張宣言の最終受信者の議論についてはセクション4.1を参照）によって許可されない限り、薬剤は、同じメッセージのヘッダ・プレフィックス値を再利用してはいけません。
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).
ヘッダ・プレフィックス値を生成するときは、この要求拡張宣言（S）（[5]、セクション13.6を参照）の関数として変化応答が変化するヘッダフィールドの使用を容易にするように、クライアントは、可能な限り一貫しているべきです。
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:
ヴァリヘッダフィールド値の接頭辞ヘッダのヘッダフィールドを含むサーバーは、その値の一部として、対応する拡張宣言フィールド名を含まなければなりません。応答は、要求にオプションの拡張宣言によって定義された16-利用変換ヘッダ・フィールドの値に依存する場合、例えば、ザ・レスポンスのヘッダフィールドを変え、このようになります。
Vary: Opt, 16-use-transform
ヴァリ：オプト、16、使い変換
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.
古いアプリケーションは、潜在的プレフィックス機構によって導入ヘッダーフィールドと競合し、この拡張機構の独立したヘッダフィールドを導入することができます。このリスクを最小限に抑えるために、接頭辞は少なくとも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).
必須およびオプション、および拡張宣言範囲の二つのタイプ：この提案は拡張宣言の強度の二種類を導入することにより、ホップホップとエンドツーエンド（セクション4.1および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).
必須拡張宣言は、最終受信者は、（セクション5及び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.
オプションの拡張宣言は、拡張の最終的な受信者が相談し、メッセージを処理する際に伸長することによって与えられた規則に準拠し、または完全に拡張宣言を無視することを示しています。エージェントは、最終的な受信者は、オプションの拡張によって参照される拡張子を理解していないかどうかを区別することができ、または単に拡張宣言を無視しなくてもよいです。
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.)
マン、オプト、Cマン、及びC-OPT：宣言強度と範囲の組み合わせは、4つの新しい一般的なHTTPヘッダフィールドによって区別される2×2行列を定義します。 （セクション4.1および4.2を参照;また、付録14を参照して、オリジンサーバとプロキシとの相互作用のテーブルを有します。）
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).
ヘッダフィールドは、それらが実際にHTTPメッセージに適用される拡張機能について説明した一般的なヘッダフィールドです。適切な場合は、オプションの宣言は（応答にそれらを適用する方法については、要求とセクション6に必須拡張宣言を適用する方法についてはセクション5を参照）任意のHTTPメッセージに適用することができます。
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:
エンドツーエンドの宣言は、宣言の最終受信者に送信されなければなりません。次のように人間とOPT一般ヘッダフィールドは、エンドツーエンドヘッダフィールドであると定義されます。
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.
セクション5および6に記載したように必須のエンドツーエンドの拡張宣言の最終受信者は、その拡張宣言を処理する必要があります。
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:
ホップバイホップ拡張宣言は、単一のHTTP接続のために有意義です。 HTTP / 1.1では、C-マン、C-OPT、及びCマン及びC-OPTによって定義された一致ヘッダプレフィックス値を持つすべてのヘッダフィールドは、Connectionヘッダフィールドによって保護されなければなりません。つまり、これらのヘッダフィールドは、（[5]、セクション14.10を参照）接続ヘッダフィールドディレクティブとして含まれるべきです。 2つのヘッダフィールドは、次の文法を持っています。
c-mandatory = "C-Man" ":" 1#ext-decl
c-optional = "C-Opt" ":" 1#ext-decl
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.
セクション5および6に記載したように必須のホップバイホップ拡張宣言の最終受信者は、その拡張宣言を処理する必要があります。
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.
2つの拡張レスポンスヘッダフィールドは、セクション5.1で説明したように必須の拡張宣言を含む要求を最終受信者によって満たされていることを示すために使用されます。拡張レスポンスヘッダフィールドは、排他的に拡張肯定応答として機能するように意図され、そして任意の他の情報を運ぶことができません。
The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled:
拡張ヘッダフィールドは、リクエスト内のすべてのエンド・ツー・エンドの必須拡張宣言が満たされたことを示すために使用されます。
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.
C-EXTレスポンスヘッダフィールドは、リクエスト内のすべてのホップバイホップ必須拡張宣言が満たされたことを示すために使用されます。
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).
HTTP / 1.1では、C-EXTヘッダフィールドは、接続ヘッダによって保護されなければならない（、[5]のセクション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.
拡張及びC-EXTヘッダフィールドは、相互に排他的ではありません。セクション5.1で説明したように、それらは両方とも同じメッセージ内で発生することができます。
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:
それは（人間又はCマンヘッダフィールドを使用して）、少なくとも1つの必須拡張宣言が含まれている場合、HTTPリクエストは、必須の要求と呼ばれています。必須リクエストのメソッド名は、「M-」を前置しなければなりません。たとえば、次のようにクライアントは、HTTPのPUTリクエストで結合rights-管理制約を表現かもしれません。
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:
必須の要求を受信し、この仕様に準拠した最終的な受信者は、下記の順序で以下のアクションを実行することによって、要求を処理しなければなりません。
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.すべての必須拡張宣言を識別し（両方のホップバイホップとエンド・ツー・エンド）。サーバは、HTTPメッセージの処理結果に影響を与えずに、オプションの宣言を無視してもよいです。
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. 1で識別されたすべての拡張機能）を調べ、彼らは、このメッセージのためにサポートされているかどうか。ない場合は、510（拡張されていない）状態コードで応答（セクション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. 2の場合）は、[5] HTTP / 1.1で定義されている拡張の既存のHTTPメソッド名のセマンティクスに従って要求を処理し、次いで、510（延長されない）ステータスコードをもたらす、またはHTTPの以降のバージョンはなかったです。 HTTPメソッド名は「M-」メソッド名接頭辞を無視することによって得ることができます。
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.
3の評価）が成功したと必須の要求が満たされた場合はセクション5.1で定義されている4.サーバが応答しなければなりません。サーバは理解し、要求内のすべての必須拡張宣言（複数可）を従わせず、要求を満たすならありません。
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).
メッセージを転送するときの必須拡張宣言の最終的な受信者として機能していないプロキシが拡張宣言や「M-」メソッド名接頭辞を削除してはなりません（必須拡張子が満たされたときを検出する方法については、セクション5.1を参照してください） 。
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.
このフィールドの各接続トークンのため、削除して接続と同じ名前を持つメッセージから任意のヘッダフィールド（複数）を無視しなければならない接続ヘッダを含むHTTP / 1.0（HTTPまたはそれ以前のバージョン）メッセージを受信したサーバ-トークン。
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.
フォローする任意の必須拡張宣言せずに「M-」メソッド名接頭辞などの必須要求を受信したサーバは510（拡張されません）応答を返さなければなりません。
The "M-" prefix is reserved by this proposal and MUST NOT be used by other HTTP extensions.
「M-」プレフィックスは、この提案によって予約されており、他のHTTPの拡張で使用してはいけません。
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.
サーバーは、それが理解し、要求内のすべての必須拡張宣言を守らない限り、すべての必須の要求を満たしていると主張してはなりません。このセクションでは、理解せずに、それは、既存のHTTPアプリケーションとの相互運用性と拡張要求は200（OK）応答で応答することによって成就したという誤った印象を与えることから、壊れたサーバを妨げるような方法でクライアントにこの情報を伝えるためのメカニズムを定義します方法。
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キャッシュにキャッシュされることを回避するために、応答がno-キャッシュキャッシュ制御ディレクティブを含まなければなりません。応答がそうでないキャッシュ可能である場合は、キャッシュなしのキャッシュ制御ディレクティブは、唯一の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):
必須の要求がHTTP / 1.0仲介プロキシによって転送された場合、これは直接要求ラインまたはViaヘッダーフィールドHTTP / 1.1の存在のいずれかによって示されます。この場合、サーバは含まなければならない（キャッシュの考慮事項に関する議論については、セクション9を参照）に等しいか、または日付ヘッダフィールドの値よりも以前の日付を有するヘッダフィールドを有効期限：
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).
任意のホップバイホップ必須拡張宣言が満たさ拡張中にあった場合、サーバが応答してC-EXTレスポンスヘッダフィールドを含まなければなりません。 C-EXTヘッダフィールドは、（[5]、セクション14.10を参照）接続ヘッダフィールドによって保護されなければなりません。
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.
拡張及びC-EXTヘッダフィールドは相互に排他的ではないことに、注意してください。彼らは、両方のホップバイホップならびにエンドツーエンドの必須拡張宣言を含む必須の要求を満たす場合の両方が対応して存在することができます。
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).
それは、その定義が必須の応答を許可またはサーバは、受信者が拡張応答を処理できることをいくつかの先験的な知識を持っている必須HTTPリクエストに応答している場合を除き、サーバはHTTP応答で必須拡張宣言を含んではいけません。サーバは、任意のHTTP応答（セクション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.
クライアントは、いずれかのクライアントが理解していないか、使用したくない必須拡張宣言を含む義務的なHTTP応答の最終的な受信者である場合は、それは500（内部サーバーエラー）応答であるかのように、それは完全な応答を捨てます。
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.
510応答は初期の要求には存在しなかった拡張機能に関する情報が含まれている場合、それは510応答で提供される情報に基づいて要求を変更することで、拡張ポリシーを満たすことができると信じる理由がある場合、クライアントは要求を繰り返す事ができます。そのエンティティは、関連する診断情報を含むことができるので、そうでない場合、クライアントは、ユーザに510応答に含まれる任意のエンティティを提示することができます。
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.
プロトコル拡張の定義が拡張識別子のアドレスで公開する必要がありますが、この仕様は、それを必要としません。唯一の絶対条件は、拡張識別子はグローバル一意識別子でなければならないということであり、その明確な名前は、明確なセマンティクスのために使用されます。
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のアドレスで利用した場合でも、ケアはそのアドレスで利用できるように仕様が時間とともに変化しないように注意しなければなりません。別の新しいセマンティクスと関連付けるかもしれないが、一つのエージェントは、古いセマンティクスを持つ識別子を関連付けることができます。
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.
例えば、人間が読み取り可能な仕様と同じアドレスに存在することができる仕様を実装するソフトウェアコンポーネントは、（コンテンツネゴシエーションによって区別されます）。ソフトウェア・コンポーネントは、クライアントとサーバを動的に拡張することができるようになる一方で、人間が読める表現は、拡張子を文書化し、導入を奨励するのに役立ちます。
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応答メッセージのキャッシュ可能性に関する追加的意味を有することができます。
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に緊密な制約が必要ない場合、発信者は拡張セマンティクスの制約の必要なレベルに対応するキャッシュ・ヘッダ・フィールドの適切な組み合わせ（のCache-Control、ヴァリ、有効期限）を含まなければなりません。
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.
冒頭で述べたよう拡張機能の動的なインストールは、別の権限（ホスト・ソフトウェアを動作させる党）の下で実行されるように一方の当事者（実装の提供者）によって書かれたソフトウェアが含まれます。これは、プロバイダ、またはプロバイダの名の下に実装を偽造悪意の第三者による「トロイの木馬」攻撃の様々なホストのパーティーを開きます。例えば、RFC2046を参照して、[4]、これらのリスクの議論についてはセクション4.5.2。
[1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[1]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、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.0"、RFC 1945、1996年5月。
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[3]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、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：メディアタイプ"、RFC 2046、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[7] Masinter、L.、 "ハイパーテキストコーヒーポット制御プロトコル（HTCPCP / 1.0）"、RFC 2324、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、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[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。
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].
ロイ・フィールディング、ロフィット・クヘア、ヤロンY. Goland、そして公園Holtmanは、この仕様のすべての段階ではコメントで彼らの努力のための特別な認識に値します。またジョシュ・コーエン、ロス・パターソン、ジム・ゲティーズ、ラリー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のアクティビティ（「http://www.w3.org/Protocols/Activity」を参照）の一部です。
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
ヘンリック・フリスティック・ニールセンマイクロソフト社1マイクロソフト道レドモンド、WA 98052、USA
EMail: frystyk@microsoft.com
メールアドレス：frystyk@microsoft.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
ポール・J.リーチマイクロソフト社1マイクロソフト道レドモンド、WA 98052、USA
EMail: paulle@microsoft.com
メールアドレス：paulle@microsoft.com
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
スコット・ローレンスAgranat Systems、Inc.の5クロックタワープレイス、スイート400メイナード、MA 01754、USA
EMail: lawrence@agranat.com
メールアドレス：lawrence@agranat.com
Appendices
付録
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)
強オプション必須オプション必須（5月）（必須）（5月）（必須）
Mandatory Standard 501 (Not Standard 501 (Not unsupported processing Implemented) processing Implemented)
必須の標準501（処理実装（ませんサポートされていない処理を実現）501標準ではありません）
Extension Standard 510 (Not Standard 510 (Not unsupported processing Extended) processing Extended) Extension Extended Extended Extended Extended supported processing processing processing processing
拡張規格510（標準ではない510（サポートされていないていない処理が拡張）拡張処理）拡張拡張拡張拡張拡張サポートされている加工処理加工処理
Table 2: Proxy Server
表2：プロキシサーバー
Scope Hop-by-hop End-to-end
スコープホップバイホップエンドツーエンド
Strength Optional Required Optional Required (may) (must) (may) (must)
強オプション必須オプション必須（5月）（必須）（5月）（必須）
Mandatory Strip 501 (Not Forward 501 (Not unsupported extension Implemented) extension Implemented) or tunnel or tunnel
必須のストリップ501（転送不可501（ませんサポートされていない拡張実装）拡張実装）またはトンネルまたはトンネル
Extension Strip 510 (Not Forward Forward unsupported extension Extended) extension extension
拡張ストリップ510（転送不可フォワード、サポートされていない拡張機能拡張）拡張拡張
Extension Extended Extended Extended Extended supported processing processing processing, processing, and strip and strip may strip may strip
拡張拡張拡張拡張拡張サポートされている加工処理加工、処理、及びストリップとストリップよいストリップよいストリップ
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リクエストとレスポンスで必須を使用して、さまざまなシナリオを示しています。取り残されている例を説明するために不可欠ではない情報が（「...」という）
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" ...
クライアントはオプションとオプト1で要求M-GET /一部-文書のHTTP / 1.1を発行：「http://www.my.com/tracking」1つの必須の拡張マン：「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必須の拡張内線を受け付けますが、のCache-Controlを無視：最大エージング= 120、キャッシュなし= "内線" オプション1。 ...クライアントは、オプションの拡張が無視されたこのケースでは見ることができません。
Table 4: Origin server with Vary header field
表4：ヴァリヘッダフィールドとオリジンサーバ
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つの必須マンで要求M-GET / P / Q HTTP / 1.1を発行します。 "のhttp：//www.x.y/transform"; NS = 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に必須なく、内線を受け入れる：男は、16-使用-変換応答日に異なります：ヴァリがあることを示し日、1998年10月25日8時12分31秒GMT要求拡張が有効期限：日、10月25日を1998年8時12分31秒GMT宣言のCache-Control：キャッシュなし= "内線"、最大エージング= 1000 ...
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プロキシ転送拡張要求
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://www.meter.org/hits" 1つの必須ホップ・バイ・C-マン：「のhttp：//クライアントは、オプション1とC-OPTで要求M-GET /一部-文書のHTTP / 1.1を発行しますwww.copy.org/rights」内線接続ホップ：C-OPT、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リクエストを転送し、かかるビア：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として失敗した510 ... M-GETメソッドに所属するすべての情報が含まれていない要求を拡張されていません
Table 6: HTTP/1.1 Proxy does not forward extended request
表6：HTTP / 1.1プロキシが拡張要求を転送しません。
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://www.meter.org/hits" 1つの必須ホップ・バイ・C-マン：「のhttp：//クライアントは、オプション1とC-OPTで要求M-GET /一部-文書のHTTP / 1.1を発行しますwww.copy.org/rights」内線接続ホップ：C-OPT、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プロキシがHTTP / 1.1 501はM-GET ...メソッドを転送するために実装され、エラーが返されていないことを拒否します
Origin server never sees the extended request
オリジンサーバは、拡張の要求を見たことがありません
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プロキシ転送拡張要求
Client issues a request M-GET /some-document HTTP/1.1 with one mandatory Man: "http://www.price.com/sale" extension ...
クライアントは1つの必須マンで要求M-GET /一部-文書の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://www.price.com/sale" HTTP / 1.0リクエスト...：HTTP / 1.0プロキシはマンとしてM-GET /一部-文書のHTTP / 1.0リクエストを転送します
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 200 OK宣言を受け入れ、内線を返します：200応答と日：日、1998年10月25日8時12分31秒GMT拡張子が有効期限：日、1998年10月25日8時12分31秒GMT確認を。 Cache-Control：キャッシュなし= "内線"、= 600応答のmax-ageが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 ...
"http://www.copy.org/rights" 1つのホップバイホップオプションのC-OPT：「のhttp：// WWWクライアントの問題は1つの必須と人間とのM-GET /一部-文書のHTTP / 1.1を要求します。 ads.org/noads」拡張接続：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.0プロキシ転送HTTP / 1.0人として1.0リクエストM-GET /一部-文書のHTTP /： "http://www.copy.org/rights" リクエストC-オプトなし：「http://www.ads。 ORG / noads」方法と接続変更：...接続のディレクティブを尊重せずに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を削除する（そして無視）任意マン： "http://www.copy.org/rights" 拡張子と転送Cマン：「http://www.ads .ORG / givemeads」接続を含む残りの部分：ヘッダフィールドを介してC-マン。それビア：1.0は、新しいまた、ホップバイホップ...必須拡張子を追加
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の両方必須内線を受け入れます。 C-EXT応答は接続できません：日付によってC-EXTのキャッシュ可能：日、1998年10月25日8時12分31秒GMT HTTP / 1.0キャッシュことができますが、有効期限：日、1998年10月25日8時12分31秒GMTは、のためにキャッシュされますCache-Controlによって1時間：キャッシュなし= "内線"、最大エージング= 3600 HTTP / 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. ...
拡張子日：日、1998年10月25日8時12分31秒GMT確認と有効期限：日、1998年10月25日は、午前8時12分31秒GMTは余りを転送するHTTP / 1.1プロキシがHTTP / 1.1 200 OKにホップバイホップ内線を削除しますCache-Control：レスポンスのキャッシュなし= "内線"、最大エージング= 3600。 ...
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。