body part

本体部分 (MIME)

[2] 本体部分 (body part) は、 multipart/* 実体に含まれるそれぞれの実体のことをいいます。

[3] ある multipart/* 実体本体部分というときは子供に当たる実体のことを指し、以降の世代の実体のことは指しません。

仕様書

定義

[1] RFC 2045 2.5

The term "body part" refers to an entity inside of a multipart entity.

用語「本文部分 body part」は多部分実体の中の実体を指します。

構文

[5] 本体部分は、MIME実体です。 ヘッダー部空行本体部で構成されます。 >>34

  1. *
    1. ヘッダー欄
  2. ?
    1. 空行
    2. 本体
[37] 本体部分RFC 822 メッセージと構文が似ていますが、 意味は異なります >>34

[38] 本体部分では、必須のヘッダー欄はありません >>34

[39] 従って本体部分空行から始まることがあります。

[25] 本体が無い場合、空行も省略できます >>34

[6] 本体部分は、その外側の境界区切子と一致する、または境界区切子から始まるを含んではなりません >>34

[21] 境界区切子の前には CRLF があります。これは区切りの一部であり、 前の本体部分前書きの一部ではありません >>34

[4] 本体部分が含まれる外側の multipart/* の構文については、 multipart/*境界区切子の項を参照してください。

HTTP における本体部分

[7] HTTTP でも multipart/*MIME の定義に従い解釈することになっています。

[8] 外側のHTTPメッセージは、MIME実体ではありません。 MIME ではなく HTTP の規定に従い解釈されます。

[9] multipart/byteranges本体部分では、 Content-Type:Content-Range: が使われます。後者は MIME に存在しない HTTP 独自のヘッダーです。前者は MIME にも存在しますが、 HTTP とは微妙に構文が違い、若干の解釈の違いが存在し得ます。

[12] HTTPクライアントがあえてここだけ MIME に従って実装しているとは思い難いので、実際には HTTP の定義に従っていると考えるべきでしょう。

[11] multipart/byteranges本体部分Content-Range: で指定された範囲のデータのみ含むものなので、 MIME実体とは性質が異なります。 Content-Type: の指定があったとしても、本体部分単体ではそのMIME型に従って解釈できる可能性は低いです。 本体部分には記述されていない Content-Encoding: が適用されている可能性もあります。

[10] このような MIMEHTTP の微妙な違いについて HTTP の仕様書は何も言及していません。

本体部分内のヘッダー

[212] 本体部分で意味が規定されているヘッダー欄は、 Content- から名前が始まるものだけです >>34

[15] それ以外のは無視して構いません >>34。 あっても構いませんが、それに依存してはなりません >>34関門でも可能なら残しておくべきではありますが、必要なら捨てても構いません >>34

[16] X- で始まる名前のを実験や私的な目的で使っても構いませんが、 関門で失われるかもしれません >>34

[213] HTTP の旧仕様である RFC 1945RFC 2068 では、任意の HTTPヘッダーを指定できるとされていました。 Expires とか Link とか、 メッセージではなく実体の頭欄・・・つまり実体頭欄ですね、 そういうのを入れることを意図していたんだと思います。

MIME 的思想では、 MIME の制定をもってメッセージ (822) と実体は意味的に分割されて、 以後新たに実体の属性を頭欄として実装するときには Content-* 名前空間に置こうと考えたのでしょう。ところが、その設計思想は HTTP の実装には反映されなかった。HTTP の設計した人達はその命名規則を理解していたかもしれませんが —きっと理解していたでしょうが、設計よりも実装がどんどん先走ったのは周知の通り。 結局、 HTTP では (名前からは機械的に決定できない) 実体頭欄だのなんたら頭欄だのという分類ができることになるわけです。

[214] ところが、 RFC 2616 で以前の規定はなくなってしまっています。 本体部分の実体の頭欄は MIME 的に解釈されると書いてあります。 やっぱり MIME と非互換ではいかんということでしょうか。

[215] Met-cast HTTP http://zowie.metnet.navy.mil/~spawar/JMV-TNG/Met-Cast-HTTP.html#samples の実装例では Content-LengthLast-Modified が本体部分の頭欄に使われています。

[19] HTTP では Content- で始まらない頭欄が、複数部分実体内でも意味を持ちえます。

[218] RFC 2068 までの規定では、本体部分の頭欄には HTTP 頭欄をいれることができましたから、素直に解釈すればそこは HTTP により解釈します。ということは、 RFC 1945 では US-ASCII + 任意の8ビット符号, RFC 2068 では ISO-8859-1 が使えるということになります。 MIME 的には US-ASCII しか使えず、それ以外は encoded-word ということになるのですが。。。

[219] RFC 2616 の規定では、 MIME 的な意味でと言っているので、 MIME の規定に従えと解釈すれば、 US-ASCII を使わないといけません。 (Semantic は MIME と言ってるけど syntax も MIME とは言ってないから ISO-8859-1 を使ってもいいという主張もできるのですが。。。)

[10] 複数部分内の実体の頭は MIME によると US-ASCII でしかありえませんけど、実際には生 JIS とか生シフトJISとかがないわけではないですね。(特に Content-Disposition: 欄のファイル名。)

[13] MIME の規定をよく読むと、 Content- から始まるもの以外は MIME 的な意味を持たないというだけで、 MIME 以外の意味を持たせることは否定していないようです。

[14] HTTPmultipart/encrypted で使われる application/HTTP-Kerberos-session-encrypted本体部分では OriginalContent: ヘッダーが使われるようです。

[22] 本体部分では、一般に必須のヘッダーはありません >>34

[23] MIME型によっては必須のものもあるかもしれません。

[24] Content-Type: ヘッダーが省略される場合、 multipart/digest では message/rfc822、 それ以外では text/plain; charset=US-ASCII が既定値です >>34

[26] Wayback Machine, https://web.archive.org/web/20041003012637/http://www.ddipocket.co.jp/p_s/service/open_net/download/oncm211.pdf#page=30

[27] >>26 DDIポケットオープンネットコンテンツ。 キャリア運用の中継サーバーと端末の間のインターネットメール風メッセージの本体部分X-PmailDX-*: ヘッダーを使っていました。

本体部分の内容符号化

[17] MIME では、 Content-Transfer-Encoding: ヘッダーにより内容転送符号化を指定し、適用することができます。

[18] multipart/*実体全体に CTE を適用することは禁止されていますが、個別の本体部分の中の本体については適用できます。

[216] MIME の Content-Transfer-Encoding, HTTP の Content-Encoding はそれぞれ固有のものです。 ではこれらを本体部分の実体の頭欄で使うことができるのか。 HTTP RFC ではどこにもその規定はありません。

[217] RFC 2616 で、本体部分実体頭欄は MIME 的に解釈されるという規定になりました。 これに従うなら、 Content-Transfer-Encoding 欄があったなら MIME 的に解釈するべきでしょう。

一方 Content-Encoding 欄は MIME で規定されていないので、 解釈なしになってしまいます。 RFC 2068 までの規定に従えば任意の HTTP 頭欄が使えるので、 HTTP 的に適当に解釈してもらえるはずなのですが・・・。

[20] HTTP の多くの実装は、 CTE に対応していません。 特に multipart/byterangesmultipart/form-data では、 CTE は利用できないと考えるべきです。