[44] Content-Disposition:
ヘッダーは、
当該実体・payload の表示・処理方法や、
表示や処理に関わるファイル名等の付加情報を指定するものです。
[106] 本ヘッダーは MIME、HTTP、SIP、multipart/form-data
で使われています。
[164] なお、ファイル名の指定については filename
もあわせて参照してください。
[15] MIME では multipart/*
により複数の本体部分を混合させることができますが、
それをどう表示するか、例えば添付ファイルとして表示するか、
一連の文書として埋め込んで表示するかを明示するものです >>11。
[89] HTTP では Content-Disposition:
ヘッダーは応答の payload をどう処理するかの追加情報や、
payload を手元に保存する時に使うファイル名等追加のメタデータを付与するものです
>>52。
[91] multipart/form-data
ではフォーム制御子の名前やファイルの名前を指定するものです。
multipart/form-data
を参照。[92] SIP では本体に含まれるデータの解釈方法を指定するものです >>14。
[104] Content-Disposition:
ヘッダーで使うdisposition型や引数は拡張可能な形になっていて、
IANA登録簿がありますが、 MIME や HTTP や SIP で共有されています。
あるプロトコルについて定義された値が他のプロトコルでも意味を持つとは限りません >>52。意味や処理方法が明確に規定されていないプロトコルで使用された際にどう処理するべきかは明記されていませんが、
認識できないdisposition型や引数として扱うものと解釈するのが自然でしょう。
[45] Content-Disposition:
ヘッダーの値は、
disposition型と、零個以上の引数です。ただし各引数の前には
;
が必要です。 >>11, >>52
[36] disposition型は、字句です。大文字・小文字不区別です >>11, >>52。
[40] 電子メールにおいては ;
の前後には空白 (RFC 822 でいう
linear-white-space / comment
、 RFC 2822/RFC 5322
でいう CFWS
) が挿入できると解釈されています。ただし MIME
RFC ではこれは明示されていません。
[96] HTTP においては ;
の前後には空白 >>52
(RFC 2616 でいう LWS
、RFC 723x でいう OWS
)
が挿入できます。
[46] MIME においては引数は RFC 2045 (字句と引用文字列) と RFC 2183 (拡張構文) の定義が参照されています >>11。 ただし RFC 2183 は後に改訂されて RFC 2231 となっています (非互換変更は無し)。
[93] HTTP においては引数は RFC 2616 (字句と引用文字列) と RFC 5987 (拡張構文) の定義が参照されています >>52。 ただし RFC 2616 は後に改訂されて RFC 723x となっています (細部に変更あり)。
[86] HTTP 送信者は、非妥当な Content-Disposition:
ヘッダーを生成してはなりません >>85。
[20] Content-Disposition:
は任意選択のヘッダーです >>11。
[60] このヘッダーは MIMEヘッダーであり、 MIME実体で指定できます。
[99] multipart/*
の各本体部分に指定できます。
multipart/form-data
の各本体部分も含まれます。
[66] また電子メール (RFC 822) メッセージのヘッダーとしても使用できます >>11。
[109] multipart/form-data
の本体部分 >>155
や VPIM >>108 では、必須となっています。
[123] SIP で S/MIME を使う場合、 Content-Disposition:
ヘッダーは推奨です >>122。
[87] HTTP 受信者は、ヘッダーが非妥当な時に回復しようとしても構いません。 (妥当性検証器などでそれが望ましい動作である場合を除き) メッセージ全体を拒絶するべきではありません。 既定の動作は、無視です。 >>85
[43] disposition型は、 Content-Disposition:
ヘッダーの最初に指定する値です。 disposition型は当該実体をどうレンダリングするべきかを主として表すものです。
[34] disposition 型の種類は少なくよく定義された状態を保つことが不要な複雑化を防ぐために好ましい >>11 とされています。
[55] それでも用途の拡大によって disposition 型を追加できるよう、拡張可能とされています >>11。 disposition型を定義したら、 IANA に登録するべきです >>42。
[56] MIME では私用のための x-token
も認められています >>11, >>42。
[17] 認識できない disposition型は、 attachment
として扱うべき (HTTP ではべき) です >>42, >>52。
[118] handling
引数に対応している場合、
未対応のdisposition型の場合の処理は同引数の値によります。
同引数が指定されない場合の既定値は required
なので、 SIP UAS は 415
を返さなければなりません。
>>117
[47] disposition型には次のものがあります。
[150] この一覧は >>149 の JSON ファイルの disposition_types
にも含まれています。
[75] signed-receipt-protocol
と
signed-receipt-micalg
は RFC 3335 を出典として IANA
に登録されていましたが、 Disposition-Notification-Options:
ヘッダーで使われるものとして定義されており、 Content-Disposition:
ヘッダーで使われるものとして登録されたのは誤りのようです。
[84] これらは2012年6月8日付けの IANA登録簿 (2012年6月2日時点) >>77 にはまだ含まれていますが、2012年9月18日付け (2013年1月15日時点) >>78 では削除されています。
[156] multipart/form-data
の本体部分では、
form-data
でなければなりません >>155。
[110] VPIM において音声はすべて inline
を指定する必要があります
>>108。
[129] 3gpp-*
のように特定の MIME型にのみ適用されると規定されているものもあります。
[114] Content-Disposition:
ヘッダーにおいて
disposition型は必須ですが、 Content-Disposition:
ヘッダーは指定されるとは限りません。
[30] MUA は、 Content-Disposition:
ヘッダーが無い場合、
適当な方法で表示して構いません >>11。
[100] HTTP では Content-Disposition:
ヘッダーが無い場合の解釈は明記されていませんが、
Content-Disposition: inline
は「既定の処理」
を表す >>52 とされており、無指定と inline
は等価ということになります。
[120] SIP では、既定のdisposition型は render
です >>14。
[121] application/sdp
では、既定のdisposition型は
session
です >>14。
[116] ISUP (application/isup
) / QSIG
(application/qsig
) では、既定の
disposition型は signal
です >>112。
[58] 引数を定義したら、 IANA に登録するべきです >>42。
[59] MIME では私用のための x-token
も認められているようです
>>42 が、disposition型とは違って構文上明確にはなっていません。
[16] 認識できない引数は、無視するべき (HTTPではべき) です >>42, >>52。
[151] この一覧は >>160 の JSON ファイルの disposition_params
にも含まれています。
[8] RFC 2183 で調子に乗って色々定義しましたが、 MIME では
filename
引数以外ほとんど使われていません。
[39] 構造的に似た Content-Type:
ヘッダーとは異なり、
Content-Disposition:
ヘッダーの引数は (特に規定がない限り)
任意の disposition型に適用できます >>42。
[94] MIME では、同名の引数の重複には言及がありません。
[95] HTTP では、同名の引数が複数ある場合、その Content-Disposition:
ヘッダーは非妥当です >>52。
[101] ただし引数の旧来の構文と拡張構文 (例えば filename
と
filename*
) はここでいう同名の引数には該当しないようです。
[103] HTTP では filename
と filename*
が指定された場合、 filename*
を採用するべきです >>102。
[125] 場合によっては (MIME型などにより) 特定の引数が必須あるいは推奨されていることがあります。
[143] SIP で使われる ms-proxy-2007fallback
引数は、
=
と値を使わず、名前だけ指定します。
[157] multipart/form-data
の本体部分では、
name
引数が必須です。
multipart/*
[23] multipart/*
そのものにも、含まれる実体本体にも
Content-Disposition:
ヘッダーを指定できます。
multipart/*
を参照。[126] handling
引数においては、
全体への指定と個別の実体本体への指定の関係について特に規定があります。
場合によっては個別の実体本体への指定は無視されます。
handling
を参照。multipart/form-data
[65] multipart/form-data
では特定の値のみが使われており、
他の multipart/*
とは使われ方が違っています。
multipart/form-data
の項をご覧ください。multipart/voice-message
[111] multipart/voice-message
(VPIM) では、
disposition型が inline
に固定されています。
また、含まれる実体本体の voice
引数の値について、
重複が認められないなどの制約があります。
[132] SDP では、 Content-Disposition:
ヘッダーに相当するものが次に示す複数の属性に対応付けられています >>131。
[142] 'file-selector'
属性の値は次の選択子で構成されます >>131。
[107] RFC 2183 はなぜか RFC 1806 の更新と記載されていますが、 正誤表で廃止に修正されています >>12。 rfc-index では廃止扱い、 tools.ietf.org のデータベース上は更新兼廃止扱いになっているようです。
Content-Disposition
の部分は参考です。HTTP では特に
filename
引数がよく使われているにもかかわらず、
標準化は中途半端な状況です。
Content-Disposition
には handling
が登録されています。[10] RFC 2616 の改訂である RFC 7231 は、 RFC 6266 で規定されているとして
Content-Disposition:
ヘッダーの規定を削除しています。
[22] 現実の実装では Content-Type: 欄の値, この Content-Disposition:
欄の値、それに URI のファイル名やその他の条件で、 WWW ブラウザ等はブラウザ内で表示したり保存ダイアログを出したり, どの部分をファイル名に採用するかを決めたり、云々でばらばらで混乱していますね。 (特に M$IE の場合は、版によっても挙動が変わったり、同じ版でも Windows Registry の設定で不可解に変化したりするそうです。)
Content-Type
:multipart/mixed
;boundary
="boundary" --boundaryContent-Type
:text/plain
;charset
=ISO-2022-JP
先日の旅行で撮った写真を送ります。 --boundaryContent-Type
:image/png
Content-Transfer-Encoding
:Base64
Content-Disposition
:inline
... Base64 で符号化した画像データ ... --boundaryContent-Type
:text/plain
;charset
=ISO-2022-JP
どうですか? 素敵なところでしょう? --boundary--
レンダリング例:
先日の旅行で撮った写真を送ります。 +---------------------------------------+ | | : (写真) : | | +---------------------------------------+ どうですか? 素敵なところでしょう?
Content-Type
:multipart/mixed
;boundary
="boundary" --boundaryContent-Type
:text/plain
;charset
=ISO-2022-JP
先日の旅行で撮った写真を送ります。 --boundaryContent-Type
:image/png
Content-Transfer-Encoding
:Base64
Content-Disposition
:attachment
... Base64 で符号化した画像データ ... --boundaryContent-Type
:text/plain
;charset
=ISO-2022-JP
どうですか? 素敵なところでしょう? --boundary--
レンダリング例:
先日の旅行で撮った写真を送ります。 /+----+ <<< +-+ | どうですか? 素敵なところでしょう? | 写真 | +------+
写真
の絵にマウス・ポインタを合わせると、
写真が表示されます。 (あくまで実現の一例です。)
<form
enctype
="multipart/form-data
"> <dl
> <dt
>名前</dt
> <dd
> <input
type
="text"name
="usrname"value
="名無しさん" /> </dd
> <dt
><input
type
="submit" /></dt
> </dl
> </form
>
このフォームから提出すると:
Content-Type
:multipart/form-data
;boundary
="boundary" --boundary Content-Type: text/plain; charset=ISO-2022-JP
Content-Disposition: form-data; name="usrname" 名無しさん --boundary--
Content-Disposition: file; filename=name.suffix
[148] >>146 と >>147 には、 Content-Disposition: mixed
を指定した multipart/*
実体の例が示されています。
>>146 は multipart/form-data
の form-data
を mixed
に置き換えたと思われ、 name
引数も指定されています。
[80] ダウンロードの動作を制御するプロトコル要素としては、
X-MS-InvokeApp:
, DownloadOptions
,
X-Download-Options:
, <a download>
があります。
[19] Content-Disposition:
欄は、 HTTP でも (特に CGI script の類で) よく使われるにも拘らず、 HTTP Core 仕様書は簡単に触れるにとどまっています。 >>18 は RFC 2184 及び現実の使用状況・ HTTP の仕様をそれなりに折り合わせたもので、実装の指針としては (期限切れ I-D ながらも) 十分な品質だと思われます。
Content-Disposition
欄ってすごい人気ですね。やっぱり「HTTP でダウンロードさせるファイル名を指定する方法」として有名だからかな?[57] IW:Google:"Content-Disposition" などで検索してみるとひどい状況。仕様書がひどくて実装もひどけりゃウェブの文書もひどくなるのは至極当然。 そうはいっても、 Google 上位サイトで仕様書を参照しているサイトはどれだけあります? 参照して無くても、読んだことがありそうな人が書いてる文書はどれだけあります? この分野全般について言えることですけど、わかりやすくて正しい解説書・解説サイトがほぼ皆無というのも問題かも。 (名無しさん 2005-01-19 08:48:15 +00:00)
[62]
JVN#95019167: Internet Explorer における MHTML によるダウンロードのダイアログボックス回避の脆弱性 (2007-06-21 17:52:08 +09:00
版) http://jvn.jp/jp/JVN%2395019167/index.html
(名無しさん 2007-06-24 07:41:31 +00:00)
[63]
JVN#27203006: Internet Explorer における MHTML により任意のスクリプトが実行される脆弱性 (2007-06-21 17:52:08 +09:00
版) http://jvn.jp/jp/JVN%2327203006/index.html
(名無しさん 2007-06-24 07:42:16 +00:00)
[64] Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding ( 版) http://greenbytes.de/tech/tc2231/
[67] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( 版) http://tools.ietf.org/html/rfc5621#section-8
[69] Test Cases for HTTP Content-Disposition header field and the Encodings defined in RFC 2047/6266 and RFC 2231/5987 ( ( 版)) http://greenbytes.de/tech/tc2231/
[70] RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) ( ( 版)) http://tools.ietf.org/html/rfc6266
[71] Test Cases for HTTP Content-Disposition header field (RFC 6266) and the Encodings defined in RFCs 2047, 2231 and 5987 ( ( 版)) http://greenbytes.de/tech/tc2231/
[72] Content-Disposition FireFoxとIEの挙動の違い - 開発者の談話室 ( ( 版)) http://www.agile-tech.com/blogs/dev/2007/12/contentdisposition.html
[79] RFC 4975 - The Message Session Relay Protocol (MSRP) ( ( 版)) http://tools.ietf.org/html/rfc4975#page-38
[81] RFC 5438 - Instant Message Disposition Notification (IMDN) ( ( 版)) http://tools.ietf.org/html/rfc5438#section-15.4
[82] IE9以降でもHTMLフォームでファイル名とファイルの中身を外部から指定できる | 徳丸浩の日記 ( ( 版)) http://blog.tokumaru.org/2014/01/ie9html.html
[83] RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/rfc5621#section-8
[416] The Return of the Content-Disposition Vulnerability in IE | セキュリティ情報 | 株式会社ラック ( ( 版)) http://www.lac.co.jp/security/alert/2003/08/21_advisory_01.html
[417] Microsoft Internet Explorer Content-Disposition Header Handling Information Disclosure Vulnerability ( ( 版)) http://tools.cisco.com/security/center/viewAlert.x?alertId=24702
[418] Microsoft Outlook Express Content Disposition Parsing Information Disclosure Vulnerability | Symantec ( ( 版)) http://www.symantec.com/security_response/vulnerability.jsp?bid=24410
[154] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part2#Downloads_and_Content-Disposition
[158] 655389 – CRLF Injection and the parsing of HTTP headers ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=655389
[162] >>161 Firefox ではダウンロードになりますが、 Chrome ではネットワークエラーになります。
[163] Preventing some CRLF header injection attacks · Issue #375 · whatwg/fetch () https://github.com/whatwg/fetch/issues/375
[165] Clarify package data algorithm for FormData (eehakkin著, ) https://github.com/whatwg/fetch/commit/e03ee6fc7f6234005a058d9784e95861b9a0a301
[166] Proposed addition of Content-Disposition to HTTP 1.1 spec () https://www.w3.org/Protocols/HTTP/Issues/content-disposition.txt
multipart/form-data
は MIME とも HTTP とも異なる構文や処理方法が採られていますので、本項では区別しています。