[要約] RFC 2774は、HTTP拡張フレームワークに関する仕様であり、HTTPプロトコルの機能を拡張するためのガイドラインを提供します。その目的は、HTTPの柔軟性と拡張性を向上させ、新しい機能やプロトコルの統合を容易にすることです。
Network Working Group H. Nielsen
Request for Comments: 2774 P. Leach
Category: Experimental Microsoft
S. Lawrence
Agranat Systems
February 2000
An HTTP Extension Framework
HTTP拡張フレームワーク
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントは、提案された標準ステータスのためにもともと要求されました。ただし、前回の呼び出し中および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;
o 単一のHTTPメッセージを拡張します。
o introducing new encodings;
o 新しいエンコーディングの紹介。
o initiating HTTP-derived protocols for new applications; to...
o 新しいアプリケーション用のHTTP由来プロトコルの開始。に...
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に割り当て、そのアドレスで利用可能な拡張機能の1つ以上の表現を作成します（セクション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アプリケーション（以下、Ultimate受信者と呼ばれる）は、拡張宣言に基づいて拡張メッセージを適切に解釈する方法を推定できます。
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」を構築します。RFC2068[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
この提案は、URL [8]で定義されている特定の機能に依存していません。これは、URNを使用して表現できない可能性があります（セクション8を参照）。したがって、より一般的な用語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
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 (":").
拡張機能は、絶対的でグローバルにユニークな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標準トラックRFCSによって定義された拡張機能への移行戦略を提供し、グローバルに一意のURIスペースとIETF標準トラックで定義されている機能をマッピングするまで、RFCSで定義されています。セクション8。
Examples of extension declarations are
拡張宣言の例は次のとおりです
"http://www.company.com/extension"; ns=11 "Range"
"http://www.company.com/extension";ns = 11 "範囲"
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.
エージェントは、extensionsのextensionsメカニズムを使用してオプションの拡張宣言パラメーターを含めることができますが、これらのパラメーターが受信者によって認識されるとは想定できません。エージェントは、ヘッダーフィールドのプレフィックス値を使用して渡される可能性のある拡張インスタンスデータを渡すためにextEntensionsを使用してはなりません（セクション3.1を参照）。認識されていないdext-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-Prefixは、動的に生成された文字列です。文字列のプレフィックスマッチングを使用して、この文字列に一致するメッセージ内のすべてのヘッダーフィールドは、その拡張宣言に属します。ヘッダーフィールドのプレフィックスを使用すると、ヘッダーのフィールド名の衝突を防ぎ、同じ拡張子を使用した複数の宣言を同じメッセージに競合することなく適用するために、プロトコルメッセージのヘッダースペースの部分空間を動的に予約できます。
Header fields using a header-prefix are of the form:
ヘッダー-Prefixを使用したヘッダーフィールドは、次の形式です。
prefixed-header = prefix-match field-name prefix-match = header-prefix "-"
prefixed-header = prefix-match field-name-name-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.
数字とダッシュ（ " - "）の組み合わせを使用したプレフィックスの形式は、拡張宣言がヘッダーフィールド名スペース全体を予約できないことを保証します。ヘッダー-Prefixメカニズムは、ヘッダーベースであるため、拡張インスタンスパラメーターを交換するための他のソリューションよりも優先され、したがって既存の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).
エージェントは、拡張機能で明示的に許可されない限り、同じメッセージでヘッダー-Prefix値を再利用してはなりません（拡張宣言の究極の受信者の議論については、セクション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).
クライアントは、リクエスト拡張宣言の関数として変化する応答でさまざまなヘッダーフィールドの使用を容易にするため、ヘッダー-Prefix値を生成するときに可能な限り一貫性を持つ必要があります（[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
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.
Header-Prefixの一貫性は、メッセージに拡張宣言を含めることに代わるものではありません：同じメッセージの拡張宣言によって定義されていないヘッダー-Prefix値を持つヘッダーフィールドは、この仕様では定義されていません。
Examples of header-prefix values are
Header-Prefix値の例は次のとおりです
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.
古いアプリケーションは、この拡張メカニズムとは無関係にヘッダーフィールドを導入する可能性があり、プレフィックスメカニズムによって導入されたヘッダーフィールドと潜在的に矛盾しています。このリスクを最小限に抑えるために、プレフィックスには少なくとも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).
この提案では、2種類の拡張宣言強度を紹介します：必須およびオプション、および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.)
宣言強度と範囲の組み合わせは、MAN、OPT、C-MAN、C-OPTの4つの新しい一般的なHTTPヘッダーフィールドによって区別される2x2マトリックスを定義します。（セクション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メッセージに適用されるかを説明するため、一般的なヘッダーフィールドです。必要に応じて、オプションの宣言をHTTPメッセージに適用できます（要求に必須の拡張宣言を適用する方法についてはセクション5を参照し、それらを応答に適用する方法についてはセクション6を参照してください）。
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:
エンドツーエンドの宣言は、宣言の究極の受信者に送信する必要があります。ManとOpt General Headerフィールドは、エンドトゥエンドヘッダーフィールドであり、次のように定義されています。
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" ...
HTTP/1.1 200 OKコンテンツレングス：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-MANおよびC-OPTによって定義されたヘッダー-Prefix値を一致させるすべてのヘッダーフィールドを、接続ヘッダーフィールドで保護する必要があります。つまり、これらのヘッダーフィールドは、接続ヘッダーフィールドディレクティブとして含まれます（[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 Headerフィールドは、要求のすべてのエンドツーエンドの必須拡張宣言が満たされたことを示すために使用されます。
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.
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.
extおよび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:
HTTP要求は、少なくとも1つの必須拡張宣言（MANまたはC-MANヘッダーフィールドを使用）を含む場合、必須要求と呼ばれます。必須要求のメソッド名は、「m-」で前に付く必要があります。たとえば、クライアントは、次のように、httpプットリクエストで拘束力のある権利管理の制約を表現する場合があります。
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）510（拡張されていない）ステータスコードが生じなかった場合、HTTP/1.1 [5]以降のHTTPで定義されている拡張機能と既存の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.
4. 3）の評価が成功し、必須の要求が満たされた場合、サーバーはセクション5.1で定義されているように応答する必要があります。サーバーは、要求のすべての必須拡張宣言を理解し、従わずにリクエストを満たしてはなりません。
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:
エンドツーエンドの必須拡張宣言が満たされた拡張機能の1つである場合、サーバーには応答にext応答ヘッダーフィールドを含める必要があります。extヘッダーフィールドが不注意にHTTP/1.1キャッシュでキャッシュされていることを回避するために、応答にはノーキャッシュキャッシュコントロールディレクティブを含める必要があります。それ以外の場合は応答がキャッシュ可能な場合、キャッシュなしのキャッシュ制御指令は、extヘッダーフィールドにのみ影響するように制限する必要があります。
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):
必須要求がHTTP/1.0中間プロキシによって転送された場合、これはリクエストラインまたはヘッダーフィールドを介して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).
ホップバイホップの必須拡張宣言が満たされた拡張機能の1つである場合、サーバーには応答にC-EXT応答ヘッダーフィールドを含める必要があります。C-Extヘッダーフィールドは、接続ヘッダーフィールドによって保護する必要があります（[5]、セクション14.10を参照）。
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.
extおよび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.
拡張メッセージの発信元は、拡張機能の存在が応答メッセージのキャッシュ制約に影響を与えるかどうかを拡張のセマンティクスから決定できるはずです。拡張機能が応答のキャッシュビリティのより緊密な制約を必要とする場合、オリジネーターには、拡張されたセマンティクスの必要なレベルの制約に対応するキャッシュヘッダーフィールド（キャッシュコントロール、変化、有効期限）の適切な組み合わせを含める必要があります。
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] Crocker、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] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[3] Bradner、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] Freed、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、「HyperText Transfer Protocol-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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）」、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension mechanism for HTTP", Work in Progress.
[9] Nielsen、H.、Connolly、D。、およびR. Khare、「Pep- HTTPの拡張メカニズム」、進行中の作業。
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].
Roy Fielding、Rohit Khare、Yaron Y. Goland、およびKoen Holtmanは、この仕様のすべての段階でコメントする努力に特別な認識に値します。また、ジョシュ・コーエン、ロス・パターソン、ジム・ゲッティズ、ラリー・マスインター、そして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").
World Wide Web Consortium（W3C）スタッフの貢献は、W3C HTTPアクティビティの一部です（ "http://www.w3.org/protocols/activity"を参照）。
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond、WA 98052、米国
EMail: frystyk@microsoft.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond、WA 98052、米国
EMail: paulle@microsoft.com
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
Scott Lawrence Agranat Systems、Inc。5 Clocktower Place、Suite 400 Maynard、MA 01754、USA
EMail: 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：Origin Server
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：ユーザーエージェントはOrigin Serverに直接
Client issues a request M-GET /some-document HTTP/1.1 with one optional and Opt: "http://www.my.com/tracking" one mandatory extension Man: "http://www.foo.com/privacy" ...
クライアントは、1つのオプションを使用してリクエストM-Get/some-document HTTP/1.1を発行し、OPT： "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.
Origin ServerはHTTP/1.1 200 OKを受け入れます。...クライアントは、この場合、オプションの拡張機能が無視されたことを確認できません。
Table 4: Origin server with Vary header field
表4：異なるヘッダーフィールドを備えたOrigin Server
Client issues a request M-GET /p/q HTTP/1.1
with one mandatory Man: "http://www.x.y/transform"; ns=16
extension 16-use-transform: xyzzy
...
Origin server accepts HTTP/1.1 200 OK
the mandatory but Ext:
indicates that the Vary: Man, 16-use-transform
response varies on the Date: Sun, 25 Oct 1998 08:12:31 GMT
request extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
declaration Cache-Control: no-cache="Ext", max-age=1000
...
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 ...
クライアントは、1つのオプションとc-optを使用して、m-get/some-document http/1.1をリクエストします。www.copy.org/rights "ホップ拡張接続：c-opt、c-man ...
HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1 the request and takes Via: 1.1 new out the connection ... headers
http/1.1プロキシはm-get/some-document http/1.1リクエストと取得：1.1 new out the connection ... headers
Origin server fails as HTTP/1.1 510 Not Extended the request does not ... contain any information belonging to the M-GET method
HTTP/1.1 510拡張されていないため、Origin Serverはリクエストが拡張されていないために失敗します... 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 ...
クライアントは、1つのオプションとc-optを使用して、m-get/some-document http/1.1をリクエストします。www.copy.org/rights "ホップ拡張接続：c-opt、c-man ...
HTTP/1.1 proxy refuses HTTP/1.1 501 Not Implemented to forward the M-GET ... method and returns an error
HTTP/1.1プロキシは、m-get ...メソッドを転送するために実装されていないHTTP/1.1 501を拒否し、エラーを返します
Origin server never sees the extended request
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プロキシフォワード拡張リクエスト
Client issues a request M-GET /some-document HTTP/1.1 with one mandatory Man: "http://www.price.com/sale" extension ...
クライアントは、1人の必須マンとのリクエストm-get/some-document http/1.1を発行します。
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/some-document http/1.0人としてのリクエスト： "http://www.price.com/sale" 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.
Origin ServerはHTTP/1.1 200 OK宣言を受け入れ、ext：200の応答と日付：日付：日付：1998年10月25日08:12:31 GMT拡張期限が切れる：日曜日、1998年10月25日08:12:31 GMT謝辞。キャッシュコントロール：no-cache = "ext"、max-age = 600応答は、http/1.1キャッシュによって10分間キャッシュできます。
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 ...
クライアントの問題は、1つの必須およびManを使用してM-Get/some-document 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プロキシはm-get/some-document http/1.0 request as http/1.0 man： "http://www.copy.org/rights" c-optなし： "http://www.ads。org/noads「メソッドと接続の変更：c-man ... connectionディレクティブ
HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights"
extension and forwards C-Man: "http://www.ads.org/givemeads"
the rest including a Connection: C-Man
via header field. It Via: 1.0 new
also add a hop-by-hop ...
mandatory extension
Origin server accepts HTTP/1.1 200 OK
both mandatory Ext:
extensions. The C-Ext
response is not Connection: C-Ext
cachable by the Date: Sun, 25 Oct 1998 08:12:31 GMT
HTTP/1.0 cache but can Expires: Sun, 25 Oct 1998 08:12:31 GMT
be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600
HTTP/1.1 caches. ...
HTTP/1.1 proxy removes HTTP/1.1 200 OK
the hop-by-hop Ext:
extension Date: Sun, 25 Oct 1998 08:12:31 GMT
acknowledgement and Expires: Sun, 25 Oct 1998 08:12:31 GMT
forwards the remainder Cache-Control: no-cache="Ext", max-age=3600
of the response. ...
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。