#?SuikaWiki/0.9 default-name="差出人不明" page-icon="メイル"
[1] [[電子メイル]]などのメッセージの[[本体]]が破損していないか調べるための情報を入れておくのがこの欄です。データの正当性検査には
[[MD5]] を使います。まあ、その名の通りですね。

[2] 定義は [[RFC1544]] <urn:ietf:rfc:1544> と [[HTTP]] [[RFC]]s
にあります。

- [9] [WEAK[2004-02-05 14:16:13 +00:00]] ''[[差出人不明]]'': 8e17e83c75274e62f9169d8c2885e512
[[#comment]]

* 仕様書から
** RFC 2068 14.16; RFC 2616 14.15 Content-MD5
> 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.)

[CODE(HTTP)[Content-MD5]] 実体頭欄は、 RFC 1864 で定義されているように、
[CODE(ABNF)[[[entity-body]]]] の末端対末端メッセージ完全性検査 (MIC)
を提供する目的の [CODE(ABNF)[entity-body]] の MD5 要約です。
(注意 : MIC は転送中の偶発的な [CODE(ABNF)[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 [DEL[may]] [INS[MAY]] be generated by an origin server [INS[or client]] to
function as an integrity check of the entity-body. Only origin
servers [INS[or clients MAY]] [DEL[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.

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

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

MD5 要約は、適用されている [CODE(ABNF)[content-coding]] を含み、
[CODE(ABNF)[message-body]] に適用される [CODE(ABNF)[transfer-encoding]]
は含まない、 [CODE(ABNF)[entity-body]] の内容に基づき計算します。
メッセージを [CODE(ABNF)[transfer-encoding]] 
つきで受信したら、その符号化は [CODE(HTTP)[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 [DEL[Transfer-Encoding]] [INS[transfer-encoding]] were being applied.

これによって、要約は [CODE(ABNF)[transfer-encoding]] 
が何も適用されていない場合の [CODE(ABNF)[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 結合媒体型 (たとえば [CODE(MIME)[[[multipart/*]]]]
や [CODE(MIME)[[[message/rfc822]]]]) について要約を計算することを認めますが、
これは前段落で定義した要約の計算方法を変更するものではありません。

>[DEL[Note:]] There are several consequences of this. The entity-body for
composite types [DEL[may]] [INS[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.

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

[INS[
>Conversion of all line breaks to CRLF MUST NOT be done before
computing or checking the digest: the line break convention used in
the text actually transmitted MUST be left unaltered when computing
the digest.

全ての改行の [[CRLF]] への変換は要約を計算・検査する前に行っては'''なりません'''。
実際に転送された文の中の改行の表記は要約の計算時には換えずに残しておかなければ'''なりません'''。
]INS]

>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. [DEL[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.]]

[CODE(HTTP)[Content-MD5]] の定義は RFC 1864 の MIME 実体本体についてのものと全く同じですが、
[CODE(HTTP)[Content-MD5]] の HTTP 実体本体への適用においては MIME
実体への適用と多少異なる点があります。一つは HTTP では MIME 
とは違って [CODE(MIME)[Content-Transfer-Encoding]] を使わず、
[CODE(HTTP)[Transfer-Encoding]] と [CODE(HTTP)[Content-Encoding]]
を使うことです。もう一つは、 HTTP は MIME より頻繁に [CODE[[[binary]]]]
内容型を使うので、その場合には要約を計算するのに使うバイト順がその型について定義された転送バイト順であることを注記する価値があるということです。
最後に、 HTTP は CRLF を使った正統形ではない幾つかの改行表記法を [CODE[text]]
型の転送で認めていることです。
**RFC 3230 (実現値要約) 5 Negotiation of 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 は [CODE(HTTP)[[[Content-MD5]]]] 頭欄を提供していますが、
これを使用すること (または使用しないこと) 
を要求するための仕組みは提供していません。
この文書で定義する [CODE(HTTP)[[[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.

まず、 [CODE(ABNF)[[[digest-algorithm]]]] 値の集合に字句
[CODE(HTTP)[[[contentMD5]]]] を加えます。
但し、この [CODE(ABNF)[digest-algorithm]] は [CODE(HTTP)[[[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.

[CODE(HTTP)[Want-Digest]] 頭欄に非零の [CODE(ABNF)[[[qvalue]]]]
の [CODE(HTTP)[contentMD5]] [CODE(ABNF)[digest-algorithm]]
を示すことは、[[送信者]]が [CODE(ABNF)[[[Request-URI]]]]
に関連付けられた[[メッセージ]]で [CODE(HTTP)[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.

[CODE(HTTP)[Want-Digest]] 頭欄に零の [CODE(ABNF)[qvalue]]
の [CODE(HTTP)[contentMD5]] [CODE(ABNF)[digest-algorithm]]
を示すことは、送信者が [CODE(ABNF)[Request-URI]]
に関連付けられたメッセージで [CODE(HTTP)[Content-MD5]]
頭を無視することを示します。

** RFC の部分の License
[[RFCのライセンス]]
*メモ

[4] [[RFC1544]>>4] の通り、 [[HTTP]] では [[multipart/*]]媒体型や
[[message/rfc822]]媒体型が[[本体]]である[[実体]]にこの欄をつけることが出来ますが、
[[MIME]] では出来ません。

[[MIME]] で [[message/news]]媒体型や
[[message/http]]媒体型が[[本体]]である[[実体]]に対して使うことが出来るのかは書いてないというか、使えるように読めますが、意図を汲むとすれば使えないと思われます。

[[message/partial]]媒体型についてはどうなのかわかりません。
- [5] 2002-10-26 (土) 17:07 ''>>4'': でも流石に [[application/news-transmission]]媒体型とかにまで「意図を汲む」のは拡大解釈しすぎな気がしますね。
- [6] [[message/external-body]]媒体型ではどうするんだっけ? RFC 1544 には書いてないや。
- [7] >>6 偽本体の [[MD5]] 値? (殆どの場合役に立たんな。) それとも本当の外部実体の MD5 値? はたまた使用禁止だろうか。実装としては混乱を防ぐために禁止して欲しい。 (けど実際誰も使ってない以上混乱しないという話もある(w)。)

[8] RFC 2068・2616 のこの部分の記述ではどうも 
[CODE(MIME)[[[multipart/*]]]] in HTTP
で [[CTE]] を使えるのかどうかがはっきりしないね。。。