The Content-MD5 entity-header field, as defined in RFC 1864 [23], 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. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.)

Content-MD5 実体頭欄は、 RFC 1864 で定義されているように、 entity-body の末端対末端メッセージ完全性検査 (MIC) を提供する目的の entity-body の MD5 要約です。 (注意 : MIC は転送中の偶発的な entity-body の修正を判定するのには良いですが、悪意のある攻撃の証拠にはなりません。)

• Content-MD5 = "Content-MD5" ":" md5-digest
• md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

The Content-MD5 header field may MAY be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients MAY may generate the Content-MD5 header field; proxies and gateways MUST NOT generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including gateways and proxies, MAY check that the digest value in this header field matches that of the entity-body as received.

Content-MD5 頭欄は、起源サーバーまたはクライアントによって entity-body の完全性検査を機能させるために生成されても構いません。 串及び関門はこれを生成してはなりません。 そうするとこの欄の末端対末端完全性検査としての値の意味をなくしてしまいます。 関門及び駆使を含む entity-body の受信者は、 この頭欄の値が受信した entity-body のものと一致するかを検査しても構いません。

The MD5 digest is computed based on the content of the entity-body, including any Content-Encoding content-coding that has been applied, but not including any transfer-encoding Transfer-Encoding that may have been applied to the message-body. If the message is received with a Transfer-Encoding transfer-encoding, that encoding must MUST be removed prior to checking the Content-MD5 value against the received entity.

MD5 要約は、適用されている content-coding を含み、 message-body に適用される transfer-encoding は含まない、 entity-body の内容に基づき計算します。 メッセージを transfer-encoding つきで受信したら、その符号化は Content-MD5 値と受信した実体を検査する前に取り除かなければなりません。

This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would be sent if no Transfer-Encoding transfer-encoding were being applied.

これによって、要約は transfer-encoding が何も適用されていない場合の entity-body のそのまま同じ順のオクテット並びについて計算したものになります。

HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), but this does not change how the digest is computed as defined in the preceding paragraph.

HTTP は RFC 1864 を拡張し、 MIME 結合媒体型 (たとえば multipart/* や message/rfc822) について要約を計算することを認めますが、 これは前段落で定義した要約の計算方法を変更するものではありません。

Note: There are several consequences of this. The entity-body for composite types may MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.

これには幾つかの重要な点があります。 結合型の entity-body は複数の本体部分を含んでいても構いませんで、 それぞれはそれぞれの MIME 頭・ HTTP 頭 (Content-MD5, Content-Transfer-Encoding, Content-Encoding を含む。) を持っています。本体部分が Content-Transfer-Encoding や Content-Encoding 頭を持っていれば、本体部分の内容はその符号化が適用されていることが仮定され、 その本体部分がそのまま、つまり、適用した状態で Content-MD5 要約に含まれます。 Transfer-Encoding 頭欄は本体部文中では認められていません。

Note: while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another is that HTTP more frequently uses binary content types than MIME, so it is worth noting that, in such cases, the byte order used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types with any of several line break conventions and not just the canonical form using CRLF. Conversion of all line breaks to CRLF should not be done before computing or checking the digest: the line break convention used in the text actually transmitted should be left unaltered when computing the digest.

Content-MD5 の定義は RFC 1864 の MIME 実体本体についてのものと全く同じですが、 Content-MD5 の HTTP 実体本体への適用においては MIME 実体への適用と多少異なる点があります。一つは HTTP では MIME とは違って Content-Transfer-Encoding を使わず、 Transfer-Encoding と Content-Encoding を使うことです。もう一つは、 HTTP は MIME より頻繁に binary 内容型を使うので、その場合には要約を計算するのに使うバイト順がその型について定義された転送バイト順であることを注記する価値があるということです。 最後に、 HTTP は CRLF を使った正統形ではない幾つかの改行表記法を text 型の転送で認めていることです。

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-Digest 頭欄はその仕組みの基礎を提供します。

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 値の集合に字句 contentMD5 を加えます。 但し、この digest-algorithm は Digest 頭欄で使用してはなりません。

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 digest-algorithm を示すことは、送信者が Request-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 digest-algorithm を示すことは、送信者が Request-URI に関連付けられたメッセージで Content-MD5 頭を無視することを示します。