[要約] RFC 3230は、HTTPでのインスタンスダイジェストに関する仕様であり、メッセージの整合性を確保するために使用されます。このRFCの目的は、クライアントがサーバーから受け取ったメッセージの整合性を検証するための手段を提供することです。
Network Working Group J. Mogul
Request for Comments: 3230 Compaq WRL
Category: Standards Track A. Van Hoff
Marimba
January 2002
Instance Digests in HTTP
httpのインスタンスダイジェスト
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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は、サーバーが応答本体のダイジェストを含めることを可能にするコンテンツMD5ヘッダーを定義します。ただし、これは、完全なファイルの内容ではなく、実際のメッセージの本文をカバーするために特異的に定義されています（応答がコンテンツレンジである場合、またはデルタエンコーディングを使用する場合、これはまったく異なる場合があります）。また、Content-MD5は1つの特定のダイジェストアルゴリズムに制限されています。SHA-1（安全なハッシュ標準）などの他のアルゴリズムは、状況によってはより適切な場合があります。最後に、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
6 IANA Considerations............................................. 10
7 Security Considerations......................................... 10
8 Acknowledgements................................................ 10
9 References...................................................... 10
10 Authors' Addresses............................................. 12
11 Full Copyright Statement....................................... 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スタックのほぼすべてのレイヤーで使用されます。ただし、保護されているデータのサイズと性質が異なるため、およびデータの整合性に対する脅威の可能性があるため、計算コストの理由で、各レイヤーで異なるダイジェストアルゴリズムが使用される場合があります。たとえば、イーサネットは環状冗長チェック（CRC）を使用します。IPv4プロトコルは、IPヘッダーに対して1つの補完チェックサムを使用します（ただし、パケットの残りの部分ではありません）。TCPは、TCPヘッダーとデータで1つの修飾チェックサムを使用し、特定の種類のプログラミングエラーを検出するために「擬似ヘッダー」を含みます。
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 Entity-Headerフィールド[...]は、エンティティボディのエンドツーエンドメッセージ整合性チェック（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の世界からコンテンツMD5を借りました。
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（部分コンテンツ）応答を送信するとき。クライアントは、キャッシュエントリをメッセージ内の部分コンテンツと組み合わせることにより、インスタンス（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.
これらの各ケースでは、サーバーはコンテンツMD5ヘッダーを使用して、応答メッセージの整合性を保護する場合があります。ただし、Content-MD5ヘッダーフィールドのマイクは、そのメッセージのエンティティのみに適用され、インスタンス全体が再組み立てされていないため、データの破損（キャッシュエントリなど）、プログラミングエラー（プログラミングエラー）のためにエラーから保護することはできません。たとえば、部分コンテンツまたはデルタの不適切な適用）、特定の悪意のある攻撃[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.
したがって、コンテンツ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認証メカニズム[5]は、特定のヘッダーフィールドを含むことを除いて、コンテンツMD5と同様のメッセージダイジェスト関数を（その他の目標に加えて）提供します。Content-MD5のように、インスタンス全体ではなく、特定のメッセージをカバーします。
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 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?
チェックサムは無料ではありません。ダイジェストを計算するには、CPUリソースが必要であり、メッセージの生成に遅延を追加する可能性があります。（これらのコストの一部は、送信者の端で慎重にキャッシュすることで回避できますが、多くの場合、そのようなキャッシュには有用なヒット率はありません。）Digestを送信すると、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.
- プライバシーダイジェストメカニズムはメッセージプライバシーを提供しません。
- authorization The digest mechanisms described here are not meant to support authorization or other kinds of access controls.
- 認証ここで説明するダイジェストメカニズムは、認可または他の種類のアクセス制御をサポートすることを目的としていません。
The Digest Access Authentication mechanism [5] can provide some integrity for certain HTTP headers, and does provide authentication.
Digest Access認証メカニズム[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.
セクション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.
エンティは、要求または応答のペイロードとして転送される情報。エンティティは、セクション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.
バリアントリソースには、任意の瞬間に1つまたは複数の表現が関連付けられている場合があります。これらの各表現は、「バリアント」と呼ばれます。「バリアント」という用語の使用は、必ずしもリソースがコンテンツネゴシエーションの対象となることを意味するわけではありません。
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は、「エンティティ」を「MIME定義のヘッダーフィールドとメッセージの内容またはマルチパートエンティティの本体内の部分の1つを指すものと定義しています。
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への応答メッセージには明確で別個の存在がありません。むしろ、リソースの現在の状態（または一連の制約の対象となるバリアント）を説明しています。HTTP/1.1仕様は、「指定されたリソースの選択されたバリアントの現在の時間に応答して返される値」を記述する用語を提供しません。これは、この概念が必要な場所でのHTTP/1.1仕様の厄介な文言につながります。
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つまたは複数のインスタンスで操作を操作して、インスタンスがサーバーからクライアントにパーツまたは複数の応答メッセージで伝えられる可能性があります。たとえば、範囲の選択またはデルタエンコーディング。インスタンス操作はエンドツーエンドであり、多くの場合、クライアントでのキャッシュの使用が含まれます。
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].
この仕様では、キーワードは「必須」、「必要はありません」、「そうは思わない」、「そうではない」、および「可能性」は、RFC 2119 [2]で説明されているように解釈されるべきです。
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は、RFC 2616 [4]で使用されているとおりです。すべてのDigest-Algorithm値は症例に伴うものです。
The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values. Initially, the registry contains the following tokens:
インターネットが割り当てられた番号当局（IANA）は、ダイジェストアルゴリズム値のレジストリとして機能します。最初に、レジストリには次のトークンが含まれています。
MD5 The MD5 algorithm, as specified in RFC 1321 [15]. The output of this algorithm is encoded using the base64 encoding [1].
MD5 RFC 1321 [15]で指定されているMD5アルゴリズム。このアルゴリズムの出力は、base64エンコード[1]を使用してエンコードされます。
SHA The SHA-1 algorithm [12]. The output of this algorithm is encoded using the base64 encoding [1].
SHA SHA-1アルゴリズム[12]。このアルゴリズムの出力は、base64エンコード[1]を使用してエンコードされます。
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.
UnixSum単一のUnix仕様バージョン2 [13]で定義されているように、Unix "sum"コマンドによって計算されたアルゴリズム。このアルゴリズムの出力は、16ビットチェックサムを表すASCII 10進数文字列です。これは、UNIX「sum」コマンドの出力の最初の単語です。
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.
unixcks unix "cksum"コマンドによって計算されたアルゴリズム、単一のunix仕様、バージョン2 [13]で定義されています。このアルゴリズムの出力は、32ビットCRCを表すASCII Digit文字列です。これは、UNIX「CKSUM」コマンドの出力の最初の単語です。
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.
他のダイジェストアルゴリズム値が定義されている場合、関連するエンコードは引用された文字列として表されるか、「;」を含めてはなりません。または、エンコーディングに使用されるキャラクターセットの「、」。
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を参照）。ダイジェストの計算に使用されるバイト順序は、インスタンスのコンテンツタイプに対して定義された伝送バイト順序です。
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.
注：Digestは、インスタンス操作の適用前に計算されます。範囲またはデルタコーディング[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
The following headers are defined.
次のヘッダーが定義されています。
The Want-Digest message header field indicates the sender's desire to receive an instance digest on messages associated with the Request-URI.
Want-Digestメッセージヘッダーフィールドは、Request-URIに関連付けられたメッセージでインスタンスダイジェストを受信したいという送信者の欲求を示しています。
Want-Digest = "Want-Digest" ":"
#(digest-algorithm [ ";" "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 Digest Headerフィールドにリストされている場合にのみ、Digest-Algorithmを受け入れることをいとわないため、その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を持つ1つ（または1つ）です。
Examples:
例：
Want-Digest: md5
Want-Digest: MD5;q=0.3, sha;q=1
The Digest message header field provides a message digest of the instance described by the message.
ダイジェストメッセージヘッダーフィールドは、メッセージで説明されているインスタンスのメッセージダイジェストを提供します。
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とメッセージに含まれるキャッシュバリダーターによって指定されています。
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.
ダイジェストヘッダーフィールドには、複数のインスタンスダイジェスト値が含まれる場合があります。これは、たとえば、さまざまなブラウザーを使用してユーザーが共有するキャッシュに居住することが期待される応答に役立ちます。
A recipient MAY ignore any or all of the instance-digests in a Digest header field.
受信者は、ダイジェストヘッダーフィールドのインスタンスダイジェストの一部またはすべてを無視する場合があります。
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
5 Negotiation of Content-MD5
5 Content-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は、コンテンツMD5ヘッダーフィールドを提供しますが、その使用（または使用）を要求するメカニズムを提供しません。このドキュメントで定義されている必要なヘッダーフィールドは、そのようなメカニズムの基礎を提供します。
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.
最初に、このダイジェストアルゴリズムをダイジェストヘッダーフィールドで使用してはならないという規定を使用して、Digest-Algorithm値のセット（セクション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.
Want-Digestヘッダーフィールドにゼロ以外のQValueを使用した「contentmd5」ダイジェストアルゴリズムの存在は、送信者がリクエスト-URIに関連付けられたメッセージにContent-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.
Want-DigestヘッダーフィールドにQValueがゼロの「ContentMD5」ダイジェストアルゴリズムの存在は、送信者がリクエスト-URIに関連付けられたメッセージにContent-MD5ヘッダーを無視することを示しています。
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]).
インターネットが割り当てられた番号局（IANA）は、ダイジェストアルゴリズム値の名前スペースを管理します。値とその意味は、独立した実装間の相互運用性が可能になるように、RFCまたは他のピアレビューされた、永続的で容易に入手可能な参照で十分に詳細に文書化する必要があります。これらの制約に従い、名前の割り当てが最初に提供され、最初に提供されます（RFC 2434 [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インスタンスデータを保護するデータ整合性メカニズムを指定します。また、少なくとも1つのスプーフィング攻撃を検出するのにも役立ちます[9]。ただし、HTTPメッセージの悪意のある改ざんに対する一般的な保護として意図されていません。
The HTTP Digest Access Authentication mechanism [5] provides some protection against malicious tampering.
HTTP Digest Access認証メカニズム[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].
Laurent Demaillyは、HTTPのアルゴリズムに依存しないチェックサムヘッダーを提案した最初の人物であった可能性があります[3]。デイブ・ラゲットは、「チェックサム」の代わりに「ダイジェスト」という用語の使用を提案しました[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] Freed、N。and N. Borenstein、N。、「Mime（多目的インターネットメールエクステンション）パート1：インターネットメッセージボディの形式を指定および記述するためのメカニズム」、RFC 2049、1996年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Laurent Demailly. Re: Revised Charter. http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0165.html.
[3] ローラン・デマイリー。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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1。」、RFC 2616、1999年6月。
[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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、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。2番目のUSENIXワークショップElectronic Commerceのワークショップ、カリフォルニア州オークランド、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] メリアム・ウェブスター。Websterの7番目の新しい大学辞書。G.＆C。Merriam Co.、マサチューセッツ州スプリングフィールド、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] Mogul、J.、Krishnamurthy、B.、Douglis、F.、Feldmann、A.、Goland、Y.、A。VanHoff、「HTTPでのエンコード」、RFC 3229、2001年12月。
[10] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[10] Myers、J。およびM. Rose、「The Content-MD5ヘッダーフィールド」、RFC 1864、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考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、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、米国商務省、1995年4月。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] オープングループ。単一のUnix仕様、バージョン2-6 Vol unix 98用のVolセット。ドキュメント番号T912、Open Group、1997年2月。
[14] Dave Raggett. Re: Revised Charter. http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0182.html.
[14] デイブ・ラゲット。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] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
10 Authors' Addresses
10著者の住所
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
ジェフリーC.モーグルウエスタンリサーチラボラトリーコンパックコンピューターコーポレーション250ユニバーシティアベニューパロアルト、カリフォルニア、94305、米国
EMail: JeffMogul@acm.org
Phone: 1 650 617 3304 (email preferred)
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043
アーサーヴァンホフマリンバ、インク440クライドアベニューマウンテンビュー、カリフォルニア94043
EMail: avh@marimba.com
Phone: 1 (650) 930 5283
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。