Content-MD5

Content-MD5: ヘッダー (MIME)

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

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

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

仕様書

歴史

HTTP

[3] 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.)

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-EncodingContent-Encoding 頭を持っていれば、本体部分の内容はその符号化が適用されていることが仮定され、 その本体部分がそのまま、つまり、適用した状態で Content-MD5 要約に含まれます。 Transfer-Encoding 頭欄は本体部文中では認められていません。

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 への変換は要約を計算・検査する前に行ってはなりません。 実際に転送された文の中の改行の表記は要約の計算時には換えずに残しておかなければなりません

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-EncodingContent-Encoding を使うことです。もう一つは、 HTTP は MIME より頻繁に binary 内容型を使うので、その場合には要約を計算するのに使うバイト順がその型について定義された転送バイト順であることを注記する価値があるということです。 最後に、 HTTP は CRLF を使った正統形ではない幾つかの改行表記法を text 型の転送で認めていることです。

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

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

[29] Want-Digest: ヘッダーにおける contentMD5q値が 0 以外の時は、 送信者Content-MD5: ヘッダーの受信を望んでいることを表します >>22

[30] Want-Digest: ヘッダーにおける contentMD5q値が 0 の時は、 送信者Content-MD5: ヘッダーを無視することを表します >>22

[28] contentMD5Digest: ヘッダーで使ってはなりません >>22

[31] このダイジェストアルゴリズムの値はなぜか IANA登録簿に登録されていません。

[9] 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 は 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-algorithmDigest 頭欄で使用してはなりません

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

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

[21] 実体MD5 なのか RFC 3230 でいう実現値MD5 なのかが明確ではないということのようです。
[13] 実装が一貫していないから削除されるなら、 HTTP のかなりの機能は削除するべきだと思うのですが...

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

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

メモ

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

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

message/partial媒体型についてはどうなのかわかりません。

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

[24] PUT Object - Amazon Simple Storage Service ( ( 版)) <http://docs.aws.amazon.com/AmazonS3/2006-03-01/API/RESTObjectPUT.html>

[25] RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES) ( ( 版)) <https://tools.ietf.org/html/rfc4236#section-3.8.2>

[26] RFC 3229 - Delta encoding in HTTP ( ( 版)) <http://tools.ietf.org/html/rfc3229#section-9>

[33] #178 (Content-MD5 and partial responses) – httpbis ( ( 版)) <https://trac.tools.ietf.org/wg/httpbis/trac/ticket/178>

[34] ( 版) <http://storage.sakura.ad.jp/pdf/base_storage_api_reference.pdf>

[36] Image API Binary Data API calls — Glance Specs 0.0.1.dev157 documentation ( 版) <https://specs.openstack.org/openstack/glance-specs/specs/api/v2/image-binary-data-api-v2.html>

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.

[37] RESTful Management of Source Images on a IIIF Server — IIIF | International Image Interoperability Framework () <http://iiif.io/api/annex/rest/#post>

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

[38] recursive remove objects expects Content-MD5 with valid SHA256 hash sent. · Issue #4383 · minio/minio () <https://github.com/minio/minio/issues/4383>

[39] PUT Object - Amazon Simple Storage Service () <http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html>

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.

[40] Common Request Headers - Amazon Simple Storage Service () <http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html>

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.

[41] ストリーミング転送  |  Cloud Storage ドキュメント  |  Google Cloud Platform () <https://cloud.google.com/storage/docs/streaming?hl=ja>

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