RFC2145 日本語訳

Network Working Group                                        J. C. Mogul
Request for Comments: 2145                                           DEC
Category: Informational                                      R. Fielding
                                                               UC Irvine
                                                               J. Gettys
                                                                     DEC
                                                              H. Frystyk
                                                                 MIT/LCS
                                                                May 1997

コメントを求めるワーキンググループJ.C.要人要求をネットワークでつないでください: 2145年12月のカテゴリ: 1997年5月にUCアーバインJ.Gettys12月のH.Frystyk MIT/LCSをさばく情報のR.

                       Use and Interpretation of
                          HTTP Version Numbers

HTTPバージョン番号の使用と解釈

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

   Distribution of this document is unlimited.  Please send comments to
   the HTTP working group at <http-wg@cuckoo.hpl.hp.com>.  Discussions
   of the working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General discussions
   about HTTP and the applications which use HTTP should take place on
   the <www-talk@w3.org> mailing list.

このドキュメントの分配は無制限です。 HTTPワーキンググループ at <http-wg@cuckoo.hpl.hp.com にコメントを送ってください、gt。 ワーキンググループの議論は<URLに格納されます: http://www.ics.uci.edu/pub/ietf/http/ >、HTTPについての一般議論とHTTPを使用するアプリケーションが the <www-talk@w3.org で行われるべきである、gt;、メーリングリスト。

Abstract

要約

   HTTP request and response messages include an HTTP protocol version
   number.  Some confusion exists concerning the proper use and
   interpretation of HTTP version numbers, and concerning
   interoperability of HTTP implementations of different protocol
   versions.  This document is an attempt to clarify the situation.  It
   is not a modification of the intended meaning of the existing
   HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention
   of the authors of those documents, and can be considered definitive
   when there is any ambiguity in those documents concerning HTTP
   version numbers, for all versions of HTTP.

HTTP要求と応答メッセージはHTTPプロトコルバージョン番号を含んでいます。 何らかの混乱がHTTPバージョン番号の適切な使用と解釈、および異なったプロトコルバージョンのHTTP実装の相互運用性に関して存在しています。 このドキュメントは状況をはっきりさせる試みです。 既存のHTTP/1.0とHTTP/1.1通のドキュメントの意図している意味の変更ではありませんが、それを、それらのドキュメントの作者の意志について説明して、HTTPバージョン番号に関してそれらのドキュメントにどんなあいまいさもあるとき、決定的であると考えることができます、HTTPのすべてのバージョンのために。

Mogul, et. al.               Informational                      [Page 1]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [1ページ]情報のRFC2145HTTPバージョン数の1997年5月

TABLE OF CONTENTS

目次

   1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . .  2
        1.1 Robustness Principle . . . . . . . . . . . . . . . . . .  3
   2 HTTP version numbers. . . . . . . . . . . . . . . . . . . . . .  3
   2.1 Proxy behavior. . . . . . . . . . . . . . . . . . . . . . . .  4
        2.2 Compatibility between minor versions of the same major
            version. . . . . . . .  . . . . . . . .  . . . . . . . .  4
        2.3 Which version number to send in a message. . . . . . . .  5
   3 Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   4 References. . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5 Authors' addresses. . . . . . . . . . . . . . . . . . . . . . .  6

1つの序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 丈夫さPrinciple. . . . . . . . . . . . . . . . . . 3 2HTTPバージョン番号。 . . . . . . . . . . . . . . . . . . . . . 3 2.1 プロキシの振舞い。 . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 同じ主要なバージョンの小さい方のバージョンの間の互換性。 . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 メッセージでどのバージョン番号を送りますか? . . . . . . . 5 3のセキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 4参照。 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 6

1 Introduction

1つの序論

   HTTP request and response messages include an HTTP protocol version
   number.  According to section 3.1 of the HTTP/1.1 specification [2],

HTTP要求と応答メッセージはHTTPプロトコルバージョン番号を含んでいます。 HTTP/1.1仕様[2]のセクション3.1によると

         HTTP uses a "<major>.<minor>" numbering scheme to indicate
      versions of the protocol. The protocol versioning policy is
      intended to allow the sender to indicate the format of a message
      and its capacity for understanding further HTTP communication,
      rather than the features obtained via that communication.  No
      change is made to the version number for the addition of message
      components which do not affect communication behavior or which
      only add to extensible field values.  The <minor> number is
      incremented when the changes made to the protocol add features
      which do not change the general message parsing algorithm, but
      which may add to the message semantics and imply additional
      capabilities of the sender. The <major> number is incremented when
      the format of a message within the protocol is changed.

HTTPは、プロトコルのバージョンを示すのに「<の主要な><の小さい方の>」ナンバリングスキームを使用します。 プロトコルversioning方針が、送付者がそのコミュニケーションで得られた特徴よりむしろさらなるHTTPコミュニケーションを理解するためにメッセージとその容量の書式を示すのを許容することを意図します。 変更を全くコミュニケーション行動に影響しないか、または広げることができる分野値に加えるだけであるメッセージコンポーネントの追加のバージョン番号にしません。 プロトコルにされた変更が一般的なメッセージ構文解析アルゴリズムを変えませんが、メッセージ意味論に加えて、送付者の追加能力を含意するかもしれない特徴を加えると、<の小さい方の>番号は増加されています。 プロトコルの中のメッセージの形式を変えるとき、<の主要な>番号は増加しています。

   The same language appears in the description of HTTP/1.0 [1].

同じ言語はHTTP/1.0[1]の記述に現れます。

   Many readers of these documents have expressed some confusion about
   the intended meaning of this policy.  Also, some people who wrote
   HTTP implementations before RFC1945 [1] was issued were not aware of
   the intentions behind the introduction of version numbers in
   HTTP/1.0.  This has led to debate and inconsistency regarding the use
   and interpretation of HTTP version numbers, and has led to
   interoperability problems in certain cases.

これらのドキュメントの多くの読者がこの方針の意図している意味に関して何らかの混乱を言い表しました。 また、RFC1945[1]が発行される前にHTTP実装を書いた何人かの人々もHTTP/1.0における、バージョン番号の導入の後ろで意志を意識していませんでした。 これは、HTTPバージョン番号の使用と解釈に関して討論と矛盾に通じて、ある場合には、相互運用性問題を引き起こしました。

Mogul, et. al.               Informational                      [Page 2]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [2ページ]情報のRFC2145HTTPバージョン数の1997年5月

   This document is an attempt to clarify the situation.  It is not a
   modification of the intended meaning of the existing HTTP/1.0 and
   HTTP/1.1 documents, but it does describe the intention of the authors
   of those documents.  In any case where either of those two documents
   is ambiguous regarding the use and interpretation of HTTP version
   numbers, this document should be considered the definitive as to the
   intentions of the designers of HTTP.

このドキュメントは状況をはっきりさせる試みです。 既存のHTTP/1.0とHTTP/1.1通のドキュメントの意図している意味の変更ではありませんが、それはそれらのドキュメントの作者の意志について説明します。 それらの2通のドキュメントのどちらかがHTTPバージョン番号の使用と解釈に関してあいまいであるどんな場合でも、このドキュメントはHTTPのデザイナーの意志に関する決定的であると考えられるべきです。

   The specification described in this document is not part of the
   specification of any individual version of HTTP, such as HTTP/1.0 or
   HTTP/1.1.  Rather, this document describes the use of HTTP version
   numbers in any version of HTTP (except for HTTP/0.9, which did not
   include version numbers).

本書では説明された仕様はHTTPのどんな個々のバージョンの仕様の一部ではありません、HTTP/1.0やHTTP/1.1のように。 むしろ、このドキュメントはHTTP(バージョン番号を含んでいなかったHTTP/0.9を除いた)のどんなバージョンでもHTTPバージョン番号の使用について説明します。

   No vendor or other provider of an HTTP implementation should claim
   any compliance with any IETF HTTP specification unless the
   implementation conditionally complies with the rules in this
   document.

実装が条件付きに本書では規則に従わない場合、HTTP実装のどんなベンダーも他のプロバイダーもどんなIETF HTTP仕様へのどんなコンプライアンスも要求するべきではありません。

1.1 Robustness Principle

1.1 堅牢性の原則

   RFC791 [4] defines the "robustness principle" in section 3.2:

RFC791[4]はセクション3.2で「堅牢性の原則」を定義します:

          an implementation must be conservative in its sending
       behavior, and liberal in its receiving behavior.

実装は、送付の振舞いで保守的であって、振舞いを受けるのにおいて寛容であるに違いありません。

   This principle applies to HTTP, as well.  It is the fundamental basis
   for interpreting any part of the HTTP specification that might still
   be ambiguous.  In particular, implementations of HTTP SHOULD NOT
   reject messages or generate errors unnecessarily.

この原則はまた、HTTPに適用されます。 それはまだあいまいであるかもしれないHTTP仕様のどんな部分も解釈する基本的な基礎です。 HTTP SHOULD NOTの実装は、特に、メッセージを拒絶するか、または不必要に誤りを生成します。

2 HTTP version numbers

2 HTTPバージョン番号

   We start by restating the language quoted above from section 3.1 of
   the HTTP/1.1 specification [2]:

私たちは上でHTTP/1.1仕様[2]のセクション3.1から引用された言語を言い直すことによって、始めます:

         It is, and has always been, the explicit intent of the
      HTTP specification that the interpretation of an HTTP message
      header does not change between minor versions of the same major
      version.

それは、あって、いつもありました、HTTPメッセージヘッダーの解釈が同じ主要なバージョンの小さい方のバージョンの間で変えないHTTP仕様の明白な意図。

         It is, and has always been, the explicit intent of the
      HTTP specification that an implementation receiving a message
      header that it does not understand MUST ignore that header.  (The
      word "ignore" has a special meaning for proxies; see section 2.1
      below.)

それは、あって、いつもありました、実装がそれが理解していないメッセージヘッダーを受ける場合そのヘッダーを無視しなければならないHTTP仕様の明白な意図。 (「無視」という言葉はプロキシのために格別の意味があります; 下のセクション2.1を見てください。)

Mogul, et. al.               Informational                      [Page 3]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [3ページ]情報のRFC2145HTTPバージョン数の1997年5月

   To make this as clear as possible:  The major version sent in a
   message MAY indicate the interpretation of other header fields.  The
   minor version sent in a message MUST NOT indicate the interpretation
   of other header fields.  This reflects the principle that the minor
   version labels the capability of the sender, not the interpretation
   of the message.

これをできるだけ明確にするように: 主要なバージョンは、メッセージが他のヘッダーフィールドの解釈を示すかもしれないのを送りました。 小さい方のバージョンは、メッセージが他のヘッダーフィールドの解釈を示してはいけないのを送りました。 これは小さい方のバージョンがメッセージの解釈ではなく、送付者の能力をラベルするという原則を反映します。

      Note: In a future version of HTTP, we may introduce a mechanism
      that explicitly requires a receiving implementation to reject a
      message if it does not understand certain headers.  For example,
      this might be implemented by means of a header that lists a set of
      other message headers that must be understood by the recipient.
      Any implementation claiming at least conditional compliance with
      this future version of HTTP would have to implement this
      mechanism.  However, no implementation claiming compliance with a
      lower HTTP version (in particular, HTTP/1.1) will have to
      implement this mechanism.

以下に注意してください。 HTTPの将来のバージョンでは、私たちは確信しているヘッダーを理解していないならメッセージを拒絶するために明らかに受信実装を必要とするメカニズムを紹介するかもしれません。 例えば、これは受取人に解釈しなければならない他のメッセージヘッダーの1セットを記載するヘッダーによって実装されるかもしれません。 少なくともHTTPのこの将来のバージョンへの条件付きのコンプライアンスを要求するどんな実装もこのメカニズムを実装しなければならないでしょう。 しかしながら、低いHTTPバージョン(特にHTTP/1.1)へのコンプライアンスを要求するどんな実装もこのメカニズムを実装してはいけないでしょう。

      This future change may be required to support the Protocol
      Extension Protocol (PEP) [3].

この将来の変化は、プロトコルExtensionプロトコル(PEP)が[3]であるとサポートしなければならないかもしれません。

   One consequence of these rules is that an HTTP/1.1 message sent to an
   HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
   constructed so that it remains a valid HTTP/1.0 message when all
   headers not defined in the HTTP/1.0 specification [1] are removed.

これらの規則の1つの結果はいつHTTP/1.0仕様[1]に基づき定義されなかったすべてのヘッダーを取り除くかがHTTP/1.0受取人(または、バージョンが未知である受取人)に送られたHTTP/1.1メッセージを構成しなければならないので有効なHTTP/1.0メッセージのままで残っているということです。

2.1 Proxy behavior

2.1 プロキシの振舞い

   A proxy MUST forward an unknown header, unless it is protected by a
   Connection header.  A proxy implementing an HTTP version >= 1.1 MUST
   NOT forward unknown headers that are protected by a Connection
   header, as described in section 14.10 of the HTTP/1.1 specification
   [2].

それがConnectionヘッダーによって保護されない場合、プロキシは未知のヘッダーを進めなければなりません。 HTTPバージョンが>=1.1であると実装するプロキシはConnectionヘッダーによって保護される未知のヘッダーを進めてはいけません、HTTP/1.1仕様[2]のセクション14.10で説明されるように。

   We remind the reader that that HTTP version numbers are hop-by-hop
   components of HTTP messages, and are not end-to-end.  That is, an
   HTTP proxy never "forwards" an HTTP version number in either a
   request or response.

私たちはそのHTTPバージョン番号がホップごとのHTTPメッセージの成分であり、終わらせる終わりでないことを読者に思い出させます。 すなわち、HTTPプロキシは要求か応答のどちらかにおけるHTTPバージョン番号を決して「進めません」。

2.2 Compatibility between minor versions of the same major version

2.2 同じ主要なバージョンの小さい方のバージョンの間の互換性

   An implementation of HTTP/x.b sending a message to a recipient whose
   version is known to be HTTP/x.a, a < b, MAY send a header that is not
   defined in the specification for HTTP/x.a.  For example, an HTTP/1.1
   server may send a "Cache-control" header to an HTTP/1.0 client; this
   may be useful if the immediate recipient is an HTTP/1.0 proxy, but
   the ultimate recipient is an HTTP/1.1 client.

バージョンがHTTP/x.aであることが知られている受取人にメッセージを送るHTTP/x.bの実装(<b)はHTTP/x.aのための仕様に基づき定義されないヘッダーを送るかもしれません。 例えば、HTTP/1.1サーバは「キャッシュ制御」ヘッダーをHTTP/1.0クライアントに送るかもしれません。 これは即座の受取人がHTTP/1.0プロキシであるなら役に立つかもしれませんが、究極の受取人はHTTP/1.1クライアントです。

Mogul, et. al.               Informational                      [Page 4]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [4ページ]情報のRFC2145HTTPバージョン数の1997年5月

   An implementation of HTTP/x.b sending a message to a recipient whose
   version is known to be HTTP/x.a, a < b, MUST NOT depend on the
   recipient understanding a header not defined in the specification for
   HTTP/x.a.  For example, HTTP/1.0 clients cannot be expected to
   understand chunked encodings, and so an HTTP/1.1 server must never
   send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request.

バージョンがHTTP/x.aであることが知られている受取人にメッセージを送るHTTP/x.bの実装(<b)はHTTP/x.aのために仕様に基づき定義されなかったヘッダーを理解している受取人に頼ってはいけません。 例えば、HTTP/1.0人のクライアントがchunked encodingsを理解していることを期待できないで、HTTP/1.1サーバは「以下を転送でコード化します」を決して送ってはいけません。 HTTP/1.0要求に対応して「chunkedしました」。

2.3 Which version number to send in a message

2.3 メッセージを送るどのバージョン番号

   The most strenuous debate over the use of HTTP version numbers has
   centered on the problem of implementations that do not follow the
   robustness principle, and which fail to produce useful results when
   they receive a message with an HTTP minor version higher than the
   minor version they implement.  We consider these implementations
   buggy, but we recognize that the robustness principle also implies
   that message senders should make concessions to buggy implementations
   when this is truly necessary for interoperation.

HTTPバージョン番号の使用に関する最も精力的な討論は堅牢性の原則に従わないで、またHTTPの小さい方のバージョンがそれらが実装する小さい方のバージョンより高い状態で彼らがメッセージを受け取るとき役に立つ結果を生まない実装の問題に集中しました。 これらの実装はバグが多いと考えますが、私たちは、また、堅牢性の原則が、これが本当にinteroperationに必要であるときに、メッセージ送付者がバギーの実装に折れて出るべきであるのを含意すると認めます。

   An HTTP client SHOULD send a request version equal to the highest
   version for which the client is at least conditionally compliant, and
   whose major version is no higher than the highest version supported
   by the server, if this is known.  An HTTP client MUST NOT send a
   version for which it is not at least conditionally compliant.

SHOULDがクライアントが条件付きに少なくとも言いなりになって、主要なバージョンがこれが知られているならサーバによってサポートされる中で最も高いバージョンほど高くない最も高いバージョンと等しい要求バージョンを送るHTTPクライアント。 HTTPクライアントはそれが少なくとも条件付きに言いなりにならないバージョンを送ってはいけません。

   An HTTP client MAY send a lower request version, if it is known that
   the server incorrectly implements the HTTP specification, but only
   after the client has determined that the server is actually buggy.

サーバが不当にHTTP仕様を履行するのが知られているなら、サーバはバグが実際に多いと決心した後を除いてだけ、HTTPクライアントが低い要求バージョンを送るかもしれません。

   An HTTP server SHOULD send a response version equal to the highest
   version for which the server is at least conditionally compliant, and
   whose major version is less than or equal to the one received in the
   request.  An HTTP server MUST NOT send a version for which it is not
   at least conditionally compliant.  A server MAY send a 505 (HTTP
   Version Not Supported) response if cannot send a response using the
   major version used in the client's request.

SHOULDがサーバが条件付きに少なくとも対応であり、主要なバージョンが、よりもの以下である最も高いバージョンと等しい応答バージョンを送るHTTPサーバは要求で受信されました。 HTTPサーバはそれが少なくとも条件付きに言いなりにならないバージョンを送ってはいけません。 サーバが505(HTTPバージョンNot Supported)応答を送るかもしれない、クライアントの要求で使用される主要なバージョンを使用することで応答を送ることができません。

   An HTTP server MAY send a lower response version, if it is known or
   suspected that the client incorrectly implements the HTTP
   specification, but this should not be the default, and this SHOULD
   NOT be done if the request version is HTTP/1.1 or greater.

HTTPサーバは低い応答バージョンを送るかもしれません、知られていたか、またはこれがクライアントが不当にHTTP仕様を履行しますが、デフォルトと、このSHOULD NOTであるべきでないと疑ったなら。要求バージョンがHTTP/1.1以上であるなら、します。

Mogul, et. al.               Informational                      [Page 5]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [5ページ]情報のRFC2145HTTPバージョン数の1997年5月

3 Security Considerations

3 セキュリティ問題

   None, except to the extent that security mechanisms introduced in one
   version of HTTP might depend on the proper interpretation of HTTP
   version numbers in older implementations.

なにも、範囲を除いて、メカニズムがHTTPの1つのバージョンで導入したそのセキュリティは、より古い実装における、HTTPバージョン番号の適切な解釈によるかもしれません。

4 References

4つの参照箇所

   1.  Berners-Lee, T.,  R. Fielding, and H. Frystyk.  Hypertext
   Transfer Protocol -- HTTP/1.0.  RFC 1945, HTTP Working Group, May,
   1996.

1. バーナーズ・リー、T.、R.フィールディング、およびH.Frystyk。 ハイパーテキスト転送プロトコル--HTTP/1.0。 RFC1945、HTTP作業部会、1996年5月。

   2.  Fielding, Roy T., Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
   Nielsen, and Tim Berners-Lee.  Hypertext Transfer Protocol --
   HTTP/1.1.  RFC 2068, HTTP Working Group, January, 1997.

2. フィールディング、ロイT.、ジムGettys、ジェフリー・C.ムガール人、Henrik Frystykニールセン、およびティム・バーナーズ・リー。 ハイパーテキスト転送プロトコル--HTTP/1.1。 RFC2068、HTTP作業部会、1997年1月。

   3.  Khare, Rohit.  HTTP/1.2 Extension Protocol (PEP).  HTTP Working
   Group, Work in Progress.

3. Khare、Rohit。 HTTP/1.2拡大プロトコル(気力)。 HTTPワーキンググループ、処理中の作業。

   4.  Postel, Jon.  Internet Protocol.  RFC 791, NIC, September, 1981.

4. ポステル、ジョン。 インターネットプロトコル。 RFC791、NIC、1981年9月。

5 Authors' addresses

5人の作者のアドレス

   Jeffrey C. Mogul
   Western Research Laboratory
   Digital Equipment Corporation
   250 University Avenue
   Palo Alto, California, 94305, USA
   Email: mogul@wrl.dec.com

Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所DEC250大学カリフォルニア 94305、米国はメールされます: mogul@wrl.dec.com

   Roy T. Fielding
   Department of Information and Computer Science
   University of California
   Irvine, CA 92717-3425, USA
   Fax: +1 (714) 824-4056
   Email: fielding@ics.uci.edu

情報の部をさばいているロイT.とカリフォルニア大学アーバイン、コンピュータサイエンスカリフォルニア92717-3425、米国Fax: +1 (714) 824-4056 メールしてください: fielding@ics.uci.edu

   Jim Gettys
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA
   Fax: +1 (617) 258 8682
   Email: jg@w3.org

正方形のケンブリッジ、ジムGettys MIT Laboratory for Computer Science545Technology MA 02139、米国Fax: +1(617) 258 8682はメールされます: jg@w3.org

Mogul, et. al.               Informational                      [Page 6]

RFC 2145                  HTTP Version Numbers                  May 1997

etムガール人、アル。 [6ページ]情報のRFC2145HTTPバージョン数の1997年5月

   Henrik Frystyk Nielsen
   W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA
   Fax: +1 (617) 258 8682
   Email: frystyk@w3.org

正方形のケンブリッジ、Henrik FrystykニールセンWWW協会MIT Laboratory for Computer Science545Technology MA 02139、米国Fax: +1(617) 258 8682はメールされます: frystyk@w3.org

Mogul, et. al.               Informational                      [Page 7]

etムガール人、アル。 情報[7ページ]