構文
[5] 本体部分は、MIME実体です。
ヘッダー部、空行、本体部で構成されます。 >>34
- *
- ヘッダー欄
- ?
- 空行
- 本体
[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] このような MIME と HTTP の微妙な違いについて HTTP
の仕様書は何も言及していません。
本体部分内のヘッダー
[212] 本体部分で意味が規定されているヘッダー欄は、
Content- から名前が始まるものだけです >>34。
[15] それ以外の欄は無視して構いません >>34。
あっても構いませんが、それに依存してはなりません >>34。
関門でも可能なら残しておくべきではありますが、必要なら捨てても構いません >>34。
[16] X- で始まる名前の欄を実験や私的な目的で使っても構いませんが、
関門で失われるかもしれません >>34。
[213] HTTP の旧仕様である RFC 1945 と RFC 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-Length や Last-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] HTTP の multipart/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/byteranges や multipart/form-data
では、 CTE は利用できないと考えるべきです。