RFC3230 日本語訳

Network Working Group                                           J. Mogul
Request for Comments: 3230                                    Compaq WRL
Category: Standards Track                                    A. Van Hoff
                                                                 Marimba
                                                            January 2002

コメントを求めるワーキンググループJ.要人要求をネットワークでつないでください: 3230年のコンパックWRLカテゴリ: 標準化過程A.バンホフマリンバ2002年1月

                        Instance Digests in HTTP

HTTPにおけるインスタンスダイジェスト

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   HTTP/1.1 defines a Content-MD5 header that allows a server to include
   a digest of the response body.  However, this is specifically defined
   to cover the body of the actual message, not the contents of the full
   file (which might be quite different, if the response is a Content-
   Range, or uses a delta encoding).  Also, the Content-MD5 is limited
   to one specific digest algorithm; other algorithms, such as SHA-1
   (Secure Hash Standard), may be more appropriate in some
   circumstances.  Finally, HTTP/1.1 provides no explicit mechanism by
   which a client may request a digest.  This document proposes HTTP
   extensions that solve these problems.

HTTP/1.1はサーバに応答本体のダイジェストを含ませるContent-MD5ヘッダーを定義します。 しかしながら、これは、完全なファイルのコンテンツではなく、実際のメッセージのボディー(応答がContent範囲である、またはデルタコード化を使用するなら、全く異なっているかもしれない)をカバーするために明確に定義されます。 また、Content-MD5は1つの特定のダイジェストアルゴリズムに制限されます。 いくつかの事情では、SHA-1などの他のアルゴリズム(安全なHash Standard)は、より適切であるかもしれません。 最終的に、HTTP/1.1はクライアントがダイジェストを要求するかもしれないどんな明白なメカニズムも提供しません。 このドキュメントはこれらの問題を解決するHTTP拡大を提案します。

Table of Contents

目次

   1 Introduction....................................................  2
        1.1 Other limitations of HTTP/1.1............................  3
   2 Goals...........................................................  4
   3 Terminology.....................................................  5
   4 Specification...................................................  6
        4.1 Protocol parameter specifications........................  6
             4.1.1 Digest algorithms.................................  6
        4.2 Instance digests.........................................  7
        4.3 Header specifications....................................  8
             4.3.1 Want-Digest.......................................  8
             4.3.2 Digest............................................  9
   5 Negotiation of Content-MD5......................................  9

1つの序論… 2 1.1 HTTP/1.1の他の制限… 3 2の目標… 4 3用語… 5 4仕様… 6 4.1 パラメタ仕様を議定書の中で述べてください… 6 4.1 .1 アルゴリズムを読みこなしてください… 6 4.2インスタンスは読みこなされます… 7 4.3 ヘッダー仕様… 8 4.3 .1 ダイジェストが欲しいです… 8 4.3 .2 読みこなしてください… 内容-MD5の9 5交渉… 9

Mogul, et. al.              Standards Track                     [Page 1]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[1ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   6 IANA Considerations............................................. 10
   7 Security Considerations......................................... 10
   8 Acknowledgements................................................ 10
   9 References...................................................... 10
   10 Authors' Addresses............................................. 12
   11 Full Copyright Statement....................................... 13

6 IANA問題… 10 7 セキュリティ問題… 10 8つの承認… 10 9つの参照箇所… 10 10人の作者のアドレス… 12 11の完全な著作権宣言文… 13

1 Introduction

1つの序論

   Although HTTP is typically layered over a reliable transport
   protocol, such as TCP, this does not guarantee reliable transport of
   information from sender to receiver.  Various problems, including
   undetected transmission errors, programming errors, corruption of
   stored data, and malicious intervention can cause errors in the
   transmitted information.

HTTPはTCPなどの信頼できるトランスポート・プロトコルの上で通常層にされますが、これは情報の信頼できる送付者から受信機までの輸送を保証しません。誤り、記憶されたデータの不正、および悪意がある介入をプログラムすることにおける非検出された伝送エラーを含む様々な問題は伝達情報量における誤りを引き起こす場合があります。

   A common approach to the problem of data integrity in a network
   protocol or distributed system, such as HTTP, is the use of digests,
   checksums, or hash values.  The sender computes a digest and sends it
   with the data; the recipient computes a digest of the received data,
   and then verifies the integrity of this data by comparing the
   digests.

HTTPなどのネットワーク・プロトコルか分散システムにおけるデータ保全の問題への一般的なアプローチはダイジェスト、チェックサム、またはハッシュ値の使用です。 送付者は、ダイジェストを計算して、データと共にそれを送ります。 受取人は、受信データのダイジェストを計算して、次に、ダイジェストを比較することによって、このデータの保全について確かめます。

   Checksums are used at virtually all layers of the IP stack.  However,
   different digest algorithms might be used at each layer, for reasons
   of computational cost, because the size and nature of the data being
   protected varies, and because the possible threats to data integrity
   vary.  For example, Ethernet uses a Cyclic Redundancy Check (CRC).
   The IPv4 protocol uses a ones-complement checksum over the IP header
   (but not the rest of the packet).  TCP uses a ones-complement
   checksum over the TCP header and data, and includes a "pseudo-header"
   to detect certain kinds of programming errors.

チェックサムはIPスタックのほとんどすべての層で使用されます。 しかしながら、異なったダイジェストアルゴリズムは各層で使用されるかもしれません、コンピュータの費用の理由で、保護されるデータのサイズと本質が異なって、データ保全への可能な脅威が異なるので。 例えば、イーサネットはCyclic Redundancy Check(CRC)を使用します。 IPv4プロトコルはIPヘッダー(しかし、パケットの残りでない)の上にもの補数のチェックサムを使用します。 TCPは、TCPヘッダーとデータの上でもの補数のチェックサムを使用して、ある種類のプログラミング・エラーを検出するために「疑似ヘッダー」を含んでいます。

   HTTP/1.1 [4] includes a mechanism for ensuring message integrity, the
   Content-MD5 header.  This header is actually defined for MIME-
   conformant messages in a standalone specification [10].  According to
   the HTTP/1.1 specification,

HTTP/1.1[4]はメッセージの保全を確実にするためのメカニズム、Content-MD5ヘッダーを含んでいます。 このヘッダーはスタンドアロン仕様[10]によるMIME conformantメッセージのために実際に定義されます。 HTTP/1.1仕様通りに

      The Content-MD5 entity-header field [...]  is an MD5 digest of the
      entity-body for the purpose of providing an end-to-end message
      integrity check (MIC) of the entity-body.

Content-MD5実体ヘッダーフィールド[…]は終わりから終わりへの実体本体のメッセージの保全チェック(MIC)を提供する目的のための実体本体のMD5ダイジェストです。

   HTTP/1.1 borrowed Content-MD5 from the MIME world based on an analogy
   between MIME messages (e.g., electronic mail messages) and HTTP
   messages (requests to or responses from an HTTP server).

HTTP/1.1はMIMEメッセージ(例えば、電子メールメッセージ)とHTTPメッセージ(HTTPサーバからの要求か応答)の間の類推に基づくMIME世界からContent-MD5を借りました。

Mogul, et. al.              Standards Track                     [Page 2]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[2ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   As discussed in more detail in section 3, this analogy between MIME
   messages and HTTP messages has resulted in some confusion.  In
   particular, while a MIME message is self-contained, an HTTP message
   might not contain the entire representation of the current state of a
   resource.  (More precisely, an HTTP response might not contain an
   entire "instance"; see section 3 for a definition of this term.)

さらに詳細にセクション3で議論するように、MIMEメッセージとHTTPメッセージの間のこの類推は何らかの混乱をもたらしました。 MIMEメッセージが自己充足的である間、特に、HTTPメッセージはリソースの現状の全体の表現を含まないかもしれません。 (より正確に、HTTP応答は全体の「インスタンス」を含まないかもしれません; 今期の定義に関してセクション3を見てください。)

   There are at least two situations where this distinction is an issue:

少なくとも2つの状況がこの区別が問題であるところにあります:

      1. When an HTTP server sends a 206 (Partial Content) response, as
         defined in HTTP/1.1.  The client may form its view of an
         instance (e.g., an HTML document) by combining a cache entry
         with the partial content in the message.

1. HTTPサーバがHTTP/1.1で定義されるように206(部分的なContent)応答を送るとき。 クライアントは、メッセージの部分的な内容にキャッシュエントリーを結合することによって、インスタンス(例えば、HTMLドキュメント)の視点を形成するかもしれません。

      2. When an HTTP server uses a "delta encoding", as proposed in a
         separate document [9].  A delta encoding represents the changes
         between the current instance of a resource and a previous
         instance, and is an efficient way of reducing the bandwidth
         required for cache updates.  The client forms its view of an
         instance by applying the delta in the message to one of its
         cache entries.

2. HTTPサーバが別々のドキュメント[9]で提案されるように「デルタコード化」を使用すると。 デルタコード化は、リソースの現在のインスタンスと前のインスタンスの間に変化を表して、キャッシュアップデートに必要である帯域幅を減少させる効率的な方法です。 クライアントは、メッセージでキャッシュエントリーの1つにデルタを適用することによって、インスタンスの視点を形成します。

   We include these two kinds of transformations in a potentially
   broader category we call "instance manipulations."

私たちは「インスタンス操作」と呼ぶ潜在的により広いカテゴリでこれらの2種類の変換を入れます。

   In each of these cases, the server might use a Content-MD5 header to
   protect the integrity of the response message.  However, because the
   MIC in a Content-MD5 header field applies only to the entity in that
   message, and not to the entire instance being reassembled, it cannot
   protect against errors due to data corruption (e.g., of cache
   entries), programming errors (e.g., improper application of a partial
   content or delta), certain malicious attacks [9], or corruption of
   certain HTTP headers in transit.

それぞれのこれらの場合では、サーバは、応答メッセージの保全を保護するのにContent-MD5ヘッダーを使用するかもしれません。 しかしながら、Content-MD5ヘッダーフィールドにおけるMICが組み立て直される全体のインスタンスではなく、そのメッセージの実体だけに適用するので、データの汚染(例えば、キャッシュエントリーの)による誤りから守ることができません、誤り(例えば、部分的な内容かデルタの不適当なアプリケーション)、ある悪意ある攻撃[9]、またはトランジットにおける、あるHTTPヘッダの不正をプログラムして。

   Thus, the Content-MD5 header, while useful and sufficient in many
   cases, is not sufficient for verifying instance integrity in all uses
   of HTTP.

したがって、多くの場合に役に立って十分ですが、Content-MD5ヘッダーはHTTPのすべての用途でインスタンス保全について確かめるのに十分ではありません。

   The Digest Authentication mechanism [5] provides (in addition to its
   other goals) a message-digest function similar to Content-MD5, except
   that it includes certain header fields.  Like Content-MD5, it covers
   a specific message, not an entire instance.

Digest Authenticationメカニズム[5]はContent-MD5と同様のメッセージダイジェスト関数を提供します(他の目標に加えて)、あるヘッダーフィールドを含んでいるのを除いて。 Content-MD5のように、それは全体のインスタンスではなく、特定のメッセージをカバーしています。

1.1 Other limitations of HTTP/1.1

1.1 HTTP/1.1の他の制限

   Checksums are not free.  Computing a digest takes CPU resources, and
   might add latency to the generation of a message.  (Some of these
   costs can be avoided by careful caching at the sender's end, but in

チェックサムは無料ではありません。 ダイジェストを計算すると、CPUリソースが取って、メッセージの世代への潜在は加えるかもしれません。 (これらのコストのいくつかをしかし、送付者の方の慎重なキャッシュ、コネで避けることができます。

Mogul, et. al.              Standards Track                     [Page 3]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[3ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   many cases such a cache would not have a useful hit ratio.)
   Transmitting a digest consumes HTTP header space (and therefore
   increases latency and network bandwidth requirements.)  If the
   message recipient does not intend to use the digest, why should the
   message sender waste resources computing and sending it?

そのようなキャッシュが役に立つヒット率に持っていない多くのケース。) ダイジェストを伝えると、HTTPヘッダスペース(そして、したがって、潜在とネットワーク帯域幅要件を増強する)は消費されます。 メッセージ受取人がダイジェストを使用しないつもりであるなら、メッセージ送付者はなぜそれを計算して、送るリソースを浪費するべきですか?

   The Content-MD5 header, of course, implies the use of the MD5
   algorithm [15].  Other algorithms, however, might be more appropriate
   for some purposes.  These include the SHA-1 algorithm [12] and
   various "fingerprinting" algorithms [7].  HTTP currently provides no
   standardized support for the use of these algorithms.

Content-MD5ヘッダーはもちろんMD5アルゴリズム[15]の使用について暗示します。 しかしながら、他のアルゴリズムはいくつかの目的のために、より適切であるかもしれません。 これらはSHA-1アルゴリズム[12]と様々な「指紋押捺」アルゴリズム[7]を含んでいます。 HTTPは現在、これらのアルゴリズムの使用の標準化されたサポートを全く提供しません。

   HTTP/1.1 apparently assumes that the choice to generate a digest is
   up to the sender, and provides no mechanism for the recipient to
   indicate whether a checksum would be useful, or what checksum
   algorithms it would understand.

HTTP/1.1は、受取人が、チェックサムが役に立つだろうかどうか、またはそれがどんなチェックサムアルゴリズムを理解しているかを示すように、ダイジェストを作る選択が送付者まであって、メカニズムを全く提供しないと明らかに仮定します。

2 Goals

2つの目標

   The goals of this proposal are:

この提案の目標は以下の通りです。

      1. Digest coverage for entire instances communicated via HTTP.

1. HTTPで伝えられた全体のインスタンスのために適用範囲を読みこなしてください。

      2. Support for multiple digest algorithms.

2. 複数のダイジェストには、アルゴリズムをサポートしてください。

      3. Negotiation of the use of digests.

3. ダイジェストの使用の交渉。

   The goals do not include:

目標は:でない

      -  header integrity
         The digest mechanisms described here cover only the bodies of
         instances, and do not protect the integrity of associated
         "entity headers" or other message headers.

- ダイジェストメカニズムがここで説明したヘッダー保全は、インスタンスのボディーだけをカバーしていて、関連「実体ヘッダー」か他のメッセージヘッダーの保全を保護しません。

      -  authentication
         The digest mechanisms described here are not meant to support
         authentication of the source of a digest or of a message or
         instance.  These mechanisms, therefore, are not sufficient
         defense against many kinds of malicious attacks.

- ここで説明されたダイジェストメカニズムがダイジェストかメッセージかインスタンスの源の認証をサポートすることになっていない認証。 したがって、これらのメカニズムは多くの種類の悪意ある攻撃に対して十分なディフェンスではありません。

      -  privacy
         Digest mechanisms do not provide message privacy.

- プライバシーDigestメカニズムはメッセージプライバシーを提供しません。

      -  authorization
         The digest mechanisms described here are not meant to support
         authorization or other kinds of access controls.

- ここで説明されたダイジェストメカニズムが承認をサポートすることになっていない承認かアクセスの他の種類が制御されます。

Mogul, et. al.              Standards Track                     [Page 4]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[4ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   The Digest Access Authentication mechanism [5] can provide some
   integrity for certain HTTP headers, and does provide authentication.

Digest Access Authenticationメカニズム[5]は、何らかの保全をあるHTTPヘッダに提供できて、認証を提供します。

3 Terminology

3 用語

   HTTP/1.1 [4] defines the following terms:

HTTP/1.1[4]は次の用語を定義します:

   resource          A network data object or service that can be
                     identified by a URI, as defined in section 3.2.
                     Resources may be available in multiple
                     representations (e.g. multiple languages, data
                     formats, size, resolutions) or vary in other ways.

リソースAネットワークデータ・オブジェクトかセクション3.2で定義されるようにURIで特定できるサービス。 リソースは、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。

   entity            The information transferred as the payload of a
                     request or response.  An entity consists of
                     metainformation in the form of entity-header fields
                     and content in the form of an entity-body, as
                     described in section 7.

情報が要求か応答のペイロードとして移した実体。 実体は実体本体の形で実体ヘッダーフィールドと内容の形でmetainformationから成ります、セクション7で説明されるように。

   variant           A resource may have one, or more than one,
                     representation(s) associated with it at any given
                     instant.  Each of these representations is termed a
                     `variant.' Use of the term `variant' does not
                     necessarily imply that the resource is subject to
                     content negotiation.

異形Aリソースには、どんな与えられた瞬間にもそれに関連している1、または1以上、表現があるかもしれません。 それぞれのこれらの表現は'異形'と呼ばれます。'異形'という用語のUseは、リソースが満足している交渉を受けることがあるのを必ず含意するというわけではありません。

   The dictionary definition for "entity" is "something that has
   separate and distinct existence and objective or conceptual reality"
   [8].  Unfortunately, the definition for "entity" in HTTP/1.1 is
   similar to that used in MIME [6], based on an entirely false analogy
   between MIME and HTTP.

「実体」のための辞書の定義は「別々の、そして、異なった存在と客観的であるか概念的な現実を持っている何か」[8]です。 残念ながら、HTTP/1.1における「実体」のための定義はMIMEとHTTPの間の完全に誤った類推に基づいてMIME[6]に使用されるそれと同様です。

   In MIME, electronic mail messages do have distinct and separate
   existences. MIME defines "entity" as something that "refers
   specifically to the MIME-defined header fields and contents of either
   a message or one of the parts in the body of a multipart entity."

MIMEでは、電子メールメッセージは異なって別々の生存を持っています。 MIMEは「特に複合実体のボディーのメッセージか部品の1つのどちらかのMIMEで定義されたヘッダーフィールドとコンテンツについて言及する」何かと「実体」を定義します。

   In HTTP, however, a response message to a GET does not have a
   distinct and separate existence.  Rather, it is describing the
   current state of a resource (or a variant, subject to a set of
   constraints).  The HTTP/1.1 specification provides no term to
   describe "the value that would be returned in response to a GET
   request at the current time for the selected variant of the specified
   resource."  This leads to awkward wordings in the HTTP/1.1
   specification in places where this concept is necessary.

しかしながら、HTTPでは、GETへの応答メッセージは異なって別々の存在を持っていません。 むしろ、それはリソース(または、1セットの規制を条件とした異形)の現状について説明しています。 HTTP/1.1仕様は、「指定されたリソースの選択された異形のための現在の時間のGET要求に対応して返される値」について説明するために用語を全く提供しません。 これはこの概念が必要である場所のHTTP/1.1仕様で厄介な言葉遣いに通じます。

Mogul, et. al.              Standards Track                     [Page 5]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[5ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   It is too late to fix the terminological failure in the HTTP/1.1
   specification, so we instead define a new term, for use in this
   document:

私たちが代わりに新学期を定義して、HTTP/1.1仕様で専門用語の失敗を修正するのは遅過ぎます、このドキュメントにおける使用のために:

   instance          The entity that would be returned in a status-200
                     response to a GET request, at the current time, for
                     the selected variant of the specified resource,
                     with the application of zero or more content-
                     codings, but without the application of any
                     instance manipulations or transfer-codings.

ゼロか、より満足しているコーディングの応用にもかかわらず、どんなインスタンス操作や転送コーディングの応用なしでも指定されたリソースの選択された異形のための現在の時間にGET要求への状態-200応答で返される実体を例証してください。

   It is convenient to think of an entity tag, in HTTP/1.1, as being
   associated with an instance, rather than an entity.  That is, for a
   given resource, two different response messages might include the
   same entity tag, but two different instances of the resource should
   never be associated with the same (strong) entity tag.

実体タグを考えるのは便利です、HTTP/1.1で、実体よりむしろインスタンスに関連しているとして。 すなわち、与えられたリソースに関しては、2つの異なった応答メッセージが同じ実体タグを含むかもしれませんが、リソースの2つの異なったインスタンスは同じ(強い)の実体タグに決して関連しているべきではありません。

   We also define this term:

また、私たちは今期を定義します:

   instance manipulation
                     An operation on one or more instances which may
                     result in an instance being conveyed from server to
                     client in parts, or in more than one response
                     message.  For example, a range selection or a delta
                     encoding.  Instance manipulations are end-to-end,
                     and often involve the use of a cache at the client.

部品、または1つ以上の応答メッセージでサーバからクライアントまで伝えられるインスタンスをもたらすかもしれない1つ以上のインスタンスにおけるインスタンス操作An操作。 例えば、範囲選択かデルタコード化。 インスタンス操作は、終わりから終わりであり、クライアントでしばしばキャッシュの使用にかかわります。

4 Specification

4 仕様

   In this specification, the key words "MUST", "MUST NOT", "SHOULD",
   "SHOULD NOT", and "MAY" are to be interpreted as described in RFC
   2119 [2].

この仕様、キーワード“MUST"、「必須NOT」“SHOULD"で「」 「5月」はRFC2119[2]で説明されるように解釈されることになっているべきです。

4.1 Protocol parameter specifications

4.1 プロトコルパラメタ仕様

4.1.1 Digest algorithms

4.1.1 ダイジェストアルゴリズム

   Digest algorithm values are used to indicate a specific digest
   computation.  For some algorithms, one or more parameters may be
   supplied.

ダイジェストアルゴリズム値は、特定のダイジェスト計算を示すのに使用されます。 いくつかのアルゴリズムにおいて、1つ以上のパラメタを提供するかもしれません。

      digest-algorithm = token

ダイジェストアルゴリズム=トークン

   The BNF for "parameter" is as is used in RFC 2616 [4].  All digest-
   algorithm values are case-insensitive.

「パラメタ」のためのBNFがRFC2616[4]で使用されるようにあります。 すべてのダイジェストアルゴリズム値が大文字と小文字を区別しないです。

Mogul, et. al.              Standards Track                     [Page 6]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[6ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   digest-algorithm values.  Initially, the registry contains the
   following tokens:

インターネットAssigned民数記Authority(IANA)はダイジェストアルゴリズム値のための登録として機能します。 初めは、登録は以下のトークンを含みます:

   MD5               The MD5 algorithm, as specified in RFC 1321 [15].
                     The output of this algorithm is encoded using the
                     base64 encoding [1].

MD5、RFC1321[15]で指定されるようなMD5アルゴリズム。 このアルゴリズムの出力は、[1]をコード化するbase64を使用することでコード化されます。

   SHA               The SHA-1 algorithm [12].  The output of this
                     algorithm is encoded using the base64 encoding [1].

SHA、SHA-1アルゴリズム[12]。 このアルゴリズムの出力は、[1]をコード化するbase64を使用することでコード化されます。

   UNIXsum           The algorithm computed by the UNIX "sum" command,
                     as defined by the Single UNIX Specification,
                     Version 2 [13].  The output of this algorithm is an
                     ASCII decimal-digit string representing the 16-bit
                     checksum, which is the first word of the output of
                     the UNIX "sum" command.

Single UNIX Specificationによって定義されるようにアルゴリズムがUNIX「合計」で計算したUNIXsumは命令して、バージョンは2[13]です。 このアルゴリズムの出力はUNIX「合計」コマンドの出力の最初の単語である16ビットのチェックサムを表すASCII10進数字ストリングです。

   UNIXcksum         The algorithm computed by the UNIX "cksum" command,
                     as defined by the Single UNIX Specification,
                     Version 2 [13].  The output of this algorithm is an
                     ASCII digit string representing the 32-bit CRC,
                     which is the first word of the output of the UNIX
                     "cksum" command.

Single UNIX Specificationによって定義されるようにアルゴリズムがUNIX"cksum"で計算したUNIXcksumは命令して、バージョンは2[13]です。 このアルゴリズムの出力はUNIX"cksum"コマンドの出力の最初の単語である32ビットのCRCを表すASCIIケタストリングです。

   If other digest-algorithm values are defined, the associated encoding
   MUST either be represented as a quoted string, or MUST NOT include
   ";" or "," in the character sets used for the encoding.

または、「他のダイジェストアルゴリズム値が定義されるなら、引用文字列として関連コード化を表さなければならない、含んではいけない、」、;、」 または、「」、」 コード化に使用される文字集合で。

4.2 Instance digests

4.2 インスタンスダイジェスト

   An instance digest is the representation of the output of a digest
   algorithm, together with an indication of the algorithm used (and any
   parameters).

インスタンスダイジェストはダイジェストアルゴリズムの出力の表現です、使用されるアルゴリズム(そして、どんなパラメタも)のしるしと共に。

       instance-digest = digest-algorithm "="
                               <encoded digest output>

インスタンスダイジェスト=ダイジェストアルゴリズム「=」<はダイジェスト出力>をコード化しました。

   The digest is computed on the entire instance associated with the
   message.  The instance is a snapshot of the resource prior to the
   application of of any instance manipulation or transfer-coding (see
   section 3).  The byte order used to compute the digest is the
   transmission byte order defined for the content-type of the instance.

ダイジェストはメッセージに関連している全体のインスタンスで計算されます。 インスタンスがアプリケーションの前のリソースのスナップである、どんなインスタンス操作か転送コード化(セクション3を見る)についても。 ダイジェストを計算するのに使用されるバイトオーダーはインスタンスのcontent typeのために定義されたトランスミッションバイトオーダーです。

Mogul, et. al.              Standards Track                     [Page 7]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[7ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

      Note: the digest is computed before the application of any
      instance manipulation.  If a range or a delta-coding [9] is used,
      the computation of the digest after the computation of the range
      or delta would not provide a digest useful for checking the
      integrity of the reassembled instance.

以下に注意してください。 ダイジェストはどんなインスタンス操作の応用の前にも計算されます。 範囲かデルタをコード化する[9]が使用されているなら、範囲かデルタの計算の後のダイジェストの計算は組み立て直されたインスタンスの保全をチェックすることの役に立つダイジェストを提供しないでしょう。

   The encoded digest output uses the encoding format defined for the
   specific digest-algorithm.  For example, if the digest-algorithm is
   "MD5", the encoding is base64; if the digest-algorithm is "UNIXsum",
   the encoding is an ASCII string of decimal digits.

コード化されたダイジェスト出力は特定のダイジェストアルゴリズムのために定義されたコード化形式を使用します。 例えば、ダイジェストアルゴリズムがそうであるなら、「MD5"、コード化はbase64です」。 ダイジェストアルゴリズムが"UNIXsum"であるなら、コード化は10進数字のASCIIストリングです。

   Examples:

例:

      MD5=HUXZLQLMuI/KZ5KDcJPcOA==
      sha=thvDyvhfIqlvFe+A9MYgxAfm1q5=
      UNIXsum=30637

MD5=HUXZLQLMuI/KZ5KDcJPcOA== sha=thvDyvhfIqlvFe+A9MYgxAfm1q5はUNIXsum=30637と等しいです。

4.3 Header specifications

4.3 ヘッダー仕様

   The following headers are defined.

以下のヘッダーは定義されます。

4.3.1 Want-Digest

4.3.1 ダイジェストが欲しいです。

   The Want-Digest message header field indicates the sender's desire to
   receive an instance digest on messages associated with the Request-
   URI.

Want-ダイジェストメッセージヘッダーフィールドはRequest URIに関連しているメッセージに関するインスタンスダイジェストを受け取る送付者の願望を示します。

       Want-Digest = "Want-Digest" ":"
                        #(digest-algorithm [ ";" "q" "=" qvalue])

「ダイジェストが欲しい=、「ダイジェストが欲しい、」、」、:、」 #(ダイジェストアルゴリズム、[「」、;、「q」「=」qvalue)

   If a digest-algorithm is not accompanied by a qvalue, it is treated
   as if its associated qvalue were 1.0.

ダイジェストアルゴリズムがqvalueによって伴われないなら、それはまるで関連qvalueが1.0であるかのように扱われます。

   The sender is willing to accept a digest-algorithm if and only if it
   is listed in a Want-Digest header field of a message, and its qvalue
   is non-zero.

そして、送付者が、ダイジェストアルゴリズムを受け入れても構わないと思っている、それがメッセージのWant-ダイジェストヘッダーフィールドで記載されていて、qvalueが非ゼロである場合にだけ。

   If multiple acceptable digest-algorithm values are given, the
   sender's preferred digest-algorithm is the one (or ones) with the
   highest qvalue.

複数の許容できるダイジェストアルゴリズム値を与えるなら、送付者の都合のよいダイジェストアルゴリズムは最も高いqvalueがあるもの(または、もの)です。

   Examples:

例:

      Want-Digest: md5
      Want-Digest: MD5;q=0.3, sha;q=1

ダイジェストが欲しいです: md5 Want-ダイジェスト: MD5; q=0.3、sha; q=1

Mogul, et. al.              Standards Track                     [Page 8]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[8ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

4.3.2 Digest

4.3.2 ダイジェスト

   The Digest message header field provides a message digest of the
   instance described by the message.

Digestメッセージヘッダーフィールドはメッセージによって説明されたインスタンスのメッセージダイジェストを提供します。

      Digest = "Digest" ":" #(instance-digest)

「ダイジェスト=「ダイジェスト」」:、」 #(インスタンスダイジェスト)

   The instance described by a message might be fully contained in the
   message-body, partially-contained in the message-body, or not at all
   contained in the message-body.  The instance is specified by the
   Request-URI and any cache-validator contained in the message.

メッセージによって説明されたインスタンスは、メッセージ本体に完全に含まれるというわけではありませんし、メッセージ本体で部分的に含まれない、またメッセージ本体に全く含まれないかもしれません。 インスタンスはRequest-URIとメッセージに含まれたどんなキャッシュ-validatorによっても指定されます。

   A Digest header field MAY contain multiple instance-digest values.
   This could be useful for responses expected to reside in caches
   shared by users with different browsers, for example.

Digestヘッダーフィールドは複数のインスタンスダイジェスト値を含むかもしれません。 これはユーザによって例えば、異なったブラウザと共有されたキャッシュで住んでいると予想された応答の役に立つかもしれません。

   A recipient MAY ignore any or all of the instance-digests in a Digest
   header field.

受取人はDigestヘッダーフィールドにおけるインスタンスダイジェストのいずれかすべてを無視するかもしれません。

   A sender MAY send an instance-digest using a digest-algorithm without
   knowing whether the recipient supports the digest-algorithm, or even
   knowing that the recipient will ignore it.

受取人がダイジェストアルゴリズムをサポートするかどうかを知っているか、または受取人がそれを無視するのを知ってさえいないダイジェストアルゴリズムを使用して、送付者はインスタンスダイジェストを送るかもしれません。

   Examples:

例:

      Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
      Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637

以下を読みこなしてください。 md5=HUXZLQLMuI/KZ5KDcJPcOA=は読みこなします: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=、unixsum=30637

5 Negotiation of Content-MD5

5 内容-MD5の交渉

   HTTP/1.1 provides a Content-MD5 header field, but does not provide
   any mechanism for requesting its use (or non-use).  The Want-Digest
   header field defined in this document provides the basis for such a
   mechanism.

HTTP/1.1は、Content-MD5ヘッダーフィールドを提供しますが、使用(または、非使用)を要求するのにどんなメカニズムも提供しません。 本書では定義されたWant-ダイジェストヘッダーフィールドはそのようなメカニズムの基礎を提供します。

   First, we add to the set of digest-algorithm values (in section
   4.1.1) the token "contentMD5", with the provision that this digest-
   algorithm MUST NOT be used in a Digest header field.

まず最初に、私たちはダイジェストアルゴリズム値(セクション4.1.1における)のセットトークン「contentMD5"、これが読みこなす支給で、ダイジェストヘッダーフィールドにアルゴリズムを使用してはいけないこと」に加えます。

   The presence of the "contentMD5" digest-algorithm with a non-zero
   qvalue in a Want-Digest header field indicates that the sender wishes
   to receive a Content-MD5 header on messages associated with the
   Request-URI.

「ダイジェストが欲しいヘッダーフィールドにおける非ゼロqvalueがあるcontentMD5"ダイジェストアルゴリズムは、要求URIに関連しているメッセージで送付者が内容-MD5ヘッダーを受け取りたがっているのを示す」存在。

   The presence of the "contentMD5" digest-algorithm with a zero qvalue
   in a Want-Digest header field indicates that the sender will ignore
   Content-MD5 headers on messages associated with the Request-URI.

存在、「ダイジェストが欲しいヘッダーフィールドにおけるゼロがあるcontentMD5"ダイジェストアルゴリズムqvalueは、送付者が要求URIに関連しているメッセージで内容-MD5ヘッダーを無視するのを示します」。

Mogul, et. al.              Standards Track                     [Page 9]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[9ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

6 IANA Considerations

6 IANA問題

   The Internet Assigned Numbers Authority (IANA) administers the name
   space for digest-algorithm values.  Values and their meaning must be
   documented in an RFC or other peer-reviewed, permanent, and readily
   available reference, in sufficient detail so that interoperability
   between independent implementations is possible.  Subject to these
   constraints, name assignments are First Come, First Served (see RFC
   2434 [11]).

インターネットAssigned民数記Authority(IANA)はダイジェストアルゴリズム値のためにスペースという名前を管理します。 RFC、または他の同輩によって見直されて、永久的で、容易に利用可能な参照に値とそれらの意味を記録しなければなりません、詳細に十分な独立している実装の間の相互運用性は可能です。 これらの規制を条件とした名前課題はFirst Come、First Servedです。(RFC2434[11])を見てください。

7 Security Considerations

7 セキュリティ問題

   This document specifies a data integrity mechanism that protects HTTP
   instance data, but not HTTP entity headers, from certain kinds of
   accidental corruption.  It is also useful in detecting at least one
   spoofing attack [9].  However, it is not intended as general
   protection against malicious tampering with HTTP messages.

このドキュメントはHTTP実体ヘッダーではなく、HTTPインスタンスデータを保護するデータ保全メカニズムを指定します、ある種類の偶然の不正から。 また、攻撃が[9]であると偽造しながら、それも少なくとも1つを検出する際に役に立ちます。 しかしながら、それはHTTPメッセージがある悪意がある改ざんに対する一般的な保護として意図しません。

   The HTTP Digest Access Authentication mechanism [5] provides some
   protection against malicious tampering.

HTTP Digest Access Authenticationメカニズム[5]は悪意がある改ざんに対する何らかの保護を提供します。

8 Acknowledgements

8つの承認

   It is not clear who first realized that the Content-MD5 header field
   is not sufficient to provide data integrity when ranges or deltas are
   used.

範囲かデルタがいつ使用されているかは、だれが、最初にContent-MD5ヘッダーフィールドがデータ保全を提供するために十分でないとわかったかが明確ではありません。

   Laurent Demailly may have been the first to suggest an algorithm-
   independent checksum header for HTTP [3].  Dave Raggett suggested the
   use of the term "digest" instead of "checksum" [14].

ローランDemaillyはHTTP[3]のために1番目にアルゴリズムの独立しているチェックサムヘッダーを示したかもしれません。 デーヴRaggettは「チェックサム」[14]の代わりに「ダイジェスト」という用語の使用を勧めました。

9 References

9つの参照箇所

   [1]  Freed, N. and N. Borenstein, N., "MIME (Multipurpose Internet
        Mail Extensions) Part One:  Mechanisms for Specifying and
        Describing the Format of Internet Message Bodies", RFC 2049,
        November 1996.

解放された[1]、N.とN.Borenstein、N.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC2049、1996年11月。

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3]  Laurent Demailly.  Re: Revised Charter.
        http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0165.html.

[3] ローランDemailly。 Re: 改訂された憲章 http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0165.html 。

   [4]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1.", RFC 2616, June 1999.

[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「ハイパーテキストはプロトコルを移します--HTTP/1.1」、RFC2616(1999年6月)

Mogul, et. al.              Standards Track                    [Page 10]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[10ページ]RFC3230インスタンスは2002年1月にHTTPで読みこなされます。

   [5]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
        Basic and Digest Access Authentication", RFC 2617, June 1999.

[5] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。

   [6]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [7]  Nevin Heintze.  Scalable Document Fingerprinting.  Proc. Second
        USENIX Workshop on Electronic Commerce, USENIX, Oakland, CA,
        November, 1996, pp. 191-200.
        http://www.cs.cmu.edu/afs/cs/user/nch/www/koala/main.html.

[7] ニーブン・ハインツェ。 スケーラブルなドキュメント指紋押捺。 Proc。 電子通商での第2USENIX Workshop、USENIX、オークランド(カリフォルニア)1996年11月、ページ 191-200 http://www.cs.cmu.edu/afs/cs/user/nch/www/koala/main.html 。

   [8]  Merriam-Webster.  Webster's Seventh New Collegiate Dictionary.
        G. & C. Merriam Co., Springfield, MA, 1963.

[8] メリアム-ウェブスター。 ウェブスターの第7新しい大学生用辞典。 G。 C.メリアム社、スプリングフィールド(MA)1963

   [9]  Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland,
        Y. and A. van Hoff, "Delta encoding in HTTP", RFC 3229, December
        2001.

[9] ムガール人、J.、Krishnamurthy、B.、Douglis、F.、フェルドマン、A.、Goland、Y.、およびA.はホフ、「HTTPにおけるデルタコード化」をバンに積みます、RFC3229、2001年12月。

   [10] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
        October 1995.

[10] マイアーズとJ.とM.ローズ、「内容-MD5ヘッダーフィールド」、RFC1864、1995年10月。

   [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[11]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [12] National Institute of Standards and Technology.  Secure Hash
        Standard.  FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION
        180-1, U.S. Department of Commerce, April, 1995.
        http://csrc.nist.gov/fips/fip180-1.txt.

[12] 米国商務省標準技術局。 ハッシュ規格を保証してください。 連邦の情報処理規格公表180-1、米国商務省、4月、1995 http://csrc.nist.gov/fips/fip180-1.txt 。

   [13] The Open Group.  The Single UNIX Specification, Version 2 - 6
        Vol Set for UNIX 98.  Document number T912, The Open Group,
        February, 1997.

[13] TheOpenGroup。 ただ一つのUNIX仕様、2--6VolがUNIX98に設定するバージョン。 1997年2月に数のT912、TheOpenGroupを記録してください。

   [14] Dave Raggett.  Re: Revised Charter.
        http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0182.html.

[14] デーヴRaggett。 Re: 改訂された憲章 http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0182.html 。

   [15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.

[15] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。

Mogul, et. al.              Standards Track                    [Page 11]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[11ページ]RFC3230例は2002年1月にHTTPで読みこなされます。

10 Authors' Addresses

10人の作者のアドレス

   Jeffrey C. Mogul
   Western Research Laboratory
   Compaq Computer Corporation
   250 University Avenue
   Palo Alto, California, 94305, U.S.A.

Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所コンパックコンピュータ社250の大学カリフォルニア 94305、米国

   EMail: JeffMogul@acm.org
   Phone: 1 650 617 3304 (email preferred)

メール: JeffMogul@acm.org 電話: 1 650 617 3304 (好まれたメール)

   Arthur van Hoff
   Marimba, Inc.
   440 Clyde Avenue
   Mountain View, CA 94043

マウンテンビュー、アーサーバンホフマリンバ社440クライドAvenueカリフォルニア 94043

   EMail: avh@marimba.com
   Phone: 1 (650) 930 5283

メール: avh@marimba.com 電話: 1 (650) 930 5283

Mogul, et. al.              Standards Track                    [Page 12]

RFC 3230                Instance Digests in HTTP            January 2002

etムガール人、アル。 標準化過程[12ページ]RFC3230例は2002年1月にHTTPで読みこなされます。

11 Full Copyright Statement

11 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Mogul, et. al.              Standards Track                    [Page 13]

etムガール人、アル。 標準化過程[13ページ]