908.txt

[1] [[電子メイル]]などのメッセージの[[本体]]が破損していないか調べるための情報を入れておくのがこの欄です。データの正当性検査には
[[MD5]] を使います。まあ、その名の通りですね。

[14] かつては [[HTTP]] でも定義されていましたが、現在は削除されています。

[35] [[電子メール]]でも [[HTTP]] でも、ほとんど使われませんでした。

* 仕様書

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

* 歴史

** HTTP

[REFS[
- [15] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2014-09-07 04:14:53 +09:00]] 版) <http://tools.ietf.org/html/rfc2616#section-14.15>
]REFS]

[FIG(quote)[
[FIGCAPTION[
[3] RFC 2068 14.16; RFC 2616 14.15 Content-MD5
]FIGCAPTION]

> 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]]
型の転送で認めていることです。
]FIG]

[20] [[RFC 3230]] は、 [CODE(HTTP)@en[[[Content-MD5:]]]] 
は[[実体本体]]に関するもので、[[実現値]]に関するものではない [SRC[>>19]] として、
新たに [CODE(HTTP)@en[[[Digest:]]]] を追加しています。

[REFS[
- [19] [CITE@en[RFC 3230 - Instance Digests in HTTP]] ([TIME[2014-08-31 18:57:37 +09:00]] 版) <http://tools.ietf.org/html/rfc3230#section-1>
- [22] [CITE@en[RFC 3230 - Instance Digests in HTTP]] ([TIME[2014-08-31 18:57:37 +09:00]] 版) <http://tools.ietf.org/html/rfc3230#section-5>
]REFS]

[27] [[ダイジェストアルゴリズム]] [DFN[[CODE(HTTP)@en[[[contentMD5]]]]]]
は、 [CODE(HTTP)@en[[[Content-MD5:]]]] [[ヘッダー]]を表します。
この値は [CODE(HTTP)@en[[[Want-Digest:]]]] [[ヘッダー]]に指定できます [SRC[>>22]]。

[29] [CODE(HTTP)@en[[[Want-Digest:]]]] [[ヘッダー]]における
[CODE(HTTP)@en[[[contentMD5]]]] の [[q値]]が 0 ''以外''の時は、
[[送信者]]が [CODE(HTTP)@en[[[Content-MD5:]]]] [[ヘッダー]]の受信を望んでいることを表します
[SRC[>>22]]。

[30] [CODE(HTTP)@en[[[Want-Digest:]]]] [[ヘッダー]]における
[CODE(HTTP)@en[[[contentMD5]]]] の [[q値]]が 0 の時は、
[[送信者]]が [CODE(HTTP)@en[[[Content-MD5:]]]] [[ヘッダー]]を無視することを表します
[SRC[>>22]]。

[28] [CODE(HTTP)@en[[[contentMD5]]]] は [CODE(HTTP)@en[[[Digest:]]]]
[[ヘッダー]]で使っては[['''なりません''']] [SRC[>>22]]。

[31] この[[ダイジェストアルゴリズム]]の値はなぜか [[IANA登録簿]]に登録されていません。
[TIME[2014-11-23T07:13:23.600Z]]

[FIG(quote)[
[FIGCAPTION[
[9] RFC 3230 (実現値要約) 5 Negotiation of Content-MD5
]FIGCAPTION]

> 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]]
頭を無視することを示します。
]FIG]

[REFS[
- [10] [CITE@en[draft-wood-dtnrg-http-dtn-delivery-07 - Using HTTP for delivery in Delay/Disruption-Tolerant Networks]]
( ([TIME[2012-02-26 11:11:35 +09:00]] 版))
<http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07#page-6>
]REFS]

[11] [[RFC 2616]] の改訂である [[RFC 7231]] は、[[部分応答]]に関する実装が一貫していないとして
[CODE(HTTP)@en[[[Content-MD5:]]]] [[ヘッダー]]を削除しています [SRC[>>12]]。

;; [21] [[実体]]の [[MD5]] なのか [[RFC 3230]] でいう[[実現値]]の [[MD5]]
なのかが明確ではないということのようです。

;; [13] 実装が一貫していないから削除されるなら、 [[HTTP]]
のかなりの機能は削除するべきだと思うのですが...

[REFS[
- [12] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#page-93>
]REFS]

[18] なお [[IANA登録簿]]は [[RFC 723x]] 以前の [[RFC 4229]] [SRC[>>17]]
を出典として状態「standard」で登録したままになっています [SRC[>>16]]。
(一覧表上は状態が空欄のままとなっています [SRC[>>16]]。) 
明確に廃止とされていないことに何らかの意図があるのかどうかははっきりしません。
[TIME[2014-11-04T14:53:55.600Z]]

[32] [[ダイジェストアルゴリズム]]の値 [CODE(HTTP)@en[[[contentMD5]]]]
はなぜか[[廃止]]されていません。

[REFS[
- [16] [CITE[Message Headers]] ([TIME[2014-10-31 18:26:49 +09:00]] 版) <http://www.iana.org/assignments/message-headers/message-headers.xhtml>
- [17] [CITE@en[RFC 4229 - HTTP Header Field Registrations]] ([TIME[2014-11-02 09:53:20 +09:00]] 版) <http://tools.ietf.org/html/rfc4229#section-2.1.28>
]REFS]

* メモ

[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]] を使えるのかどうかがはっきりしないね。。。

[24] [CITE[PUT Object - Amazon Simple Storage Service]]
( ([TIME[2013-01-04 00:35:41 +09:00]] 版))
<http://docs.aws.amazon.com/AmazonS3/2006-03-01/API/RESTObjectPUT.html>

[25] [CITE@en[RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)]]
( ([TIME[2014-09-22 20:05:44 +09:00]] 版))
<https://tools.ietf.org/html/rfc4236#section-3.8.2>

[26] [CITE@en[RFC 3229 - Delta encoding in HTTP]]
( ([TIME[2014-10-26 21:15:25 +09:00]] 版))
<http://tools.ietf.org/html/rfc3229#section-9>

[33] [CITE[#178 (Content-MD5 and partial responses) – httpbis]]
( ([TIME[2014-11-23 16:28:52 +09:00]] 版))
<https://trac.tools.ietf.org/wg/httpbis/trac/ticket/178>

[34] ([TIME[2014-07-03 18:27:57 +09:00]] 版)
<http://storage.sakura.ad.jp/pdf/base_storage_api_reference.pdf>

[FIG(quote)[
[FIGCAPTION[
[36] [CITE[Image API Binary Data API calls — Glance Specs 0.0.1.dev157 documentation]]
([TIME[2016-03-11 02:50:48 +09:00]] 版)
<https://specs.openstack.org/openstack/glance-specs/specs/api/v2/image-binary-data-api-v2.html>
]FIGCAPTION]

> The Content-MD5 header will contain an MD5 checksum of the image data. Clients are encouraged to verify the integrity of the image data they receive using this checksum.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[37] [CITE@en[RESTful Management of Source Images on a IIIF Server — IIIF | International Image Interoperability Framework]]
([TIME[2017-09-15 08:03:41 +09:00]])
<http://iiif.io/api/annex/rest/#post>
]FIGCAPTION]

> Content-MD5	Response	yes	As a verification that the image was received intact.

]FIG]


[38] [CITE@en[recursive remove objects expects Content-MD5 with valid SHA256 hash sent. · Issue #4383 · minio/minio]]
([TIME[2017-11-07 16:25:30 +09:00]])
<https://github.com/minio/minio/issues/4383>

[FIG(quote)[
[FIGCAPTION[
[39] [CITE[PUT Object - Amazon Simple Storage Service]]
([TIME[2017-11-07 07:46:54 +09:00]])
<http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html>
]FIGCAPTION]

> Content-MD5	
> The base64-encoded 128-bit MD5 digest of the message (without the headers) according to RFC 1864. This header can be used as a message integrity check to verify that the data is the same data that was originally sent. Although it is optional, we recommend using the Content-MD5 mechanism as an end-to-end integrity check.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[40] [CITE[Common Request Headers - Amazon Simple Storage Service]]
([TIME[2017-11-07 07:46:54 +09:00]])
<http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html>
]FIGCAPTION]

> Content-MD5	
> The base64 encoded 128-bit MD5 digest of the message (without the headers) according to RFC 1864. This header can be used as a message integrity check to verify that the data is the same data that was originally sent. Although it is optional, we recommend using the Content-MD5 mechanism as an end-to-end integrity check. 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[41] [CITE@ja[ストリーミング転送  |  Cloud Storage ドキュメント  |  Google Cloud Platform]]
([TIME[2017-12-06 16:07:29 +09:00]])
<https://cloud.google.com/storage/docs/streaming?hl=ja>
]FIGCAPTION]

> Google Cloud Storage では、ストリーミング アップロードの開始時点の Content-MD5 と完了したアップロードの Content-MD5 を比較しません。これは、アップロードが完了するまでは Google Cloud Storage はアップロードするコンテンツについて一切把握できず、アップロード開始時点に Content-MD5 を作成できないためです。そのため、ストリーミング アップロードが完了した後、整合性をチェックする必要があります。

]FIG]