[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
が登録されています。The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in RFC 1806 [35].
Content-Disposition 応答頭欄は、
利用者が内容をファイルに保存する場合の既定のファイル名を起源鯖が提案するための手段として提案されています。
この使用は RFC1806 の Content-Disposition
の定義から派生しています。
- content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm )
- disposition-type = "attachment" | disp-extension-token
- disposition-parm = filename-parm | disp-extension-parm
- filename-parm = "filename" "=" quoted-string
- disp-extension-token = token
- disp-extension-parm = token "=" ( token | quoted-string )
An example is
- Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only.
現時点では filename-parm 引数だけが HTTP
実装に適用されると信じられていますが、
受信した利用者エージェントは、 filename-parm
引数に示されたいかなるディレクトリ経路情報も尊重するべきではありません。
ファイル名は最終部品のみとして扱うべきです。
If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.
この頭が応答で application/octet-stream
内容型と共に使われている場合は、利用者エージェントは応答を表示するべきではなく、
「応答を保存・・・」対話に直接入るべきであることを暗に提案しています。
See section 15.5 for Content-Disposition security issues.
RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.
HTTP でしばしば実装される Content-Disposition
頭は RFC 1806 から派生したものですが、 RFC 1806
には多くの非常に深刻な安全上の問題があります。 Content-Disposition
は HTTP 規格の一部ではありませんが、広く実装されていることから、
その使用と危険を実装者のために文章化しています。
詳しくは (RFC 1806 を更新する) RFC 2183 をご覧下さい。
[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/pngContent-Transfer-Encoding:Base64Content-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/pngContent-Transfer-Encoding:Base64Content-Disposition:attachment... Base64 で符号化した画像データ ... --boundaryContent-Type:text/plain;charset=ISO-2022-JPどうですか? 素敵なところでしょう? --boundary--
レンダリング例:
先日の旅行で撮った写真を送ります。 /+----+
<<< +-+ |
どうですか? 素敵なところでしょう? | 写真 |
+------+写真
の絵にマウス・ポインタを合わせると、
写真が表示されます。 (あくまで実現の一例です。)
<formenctype="multipart/form-data"> <dl> <dt>名前</dt> <dd> <inputtype="text"name="usrname"value="名無しさん" /> </dd> <dt><inputtype="submit" /></dt> </dl> </form>
このフォームから提出すると:
Content-Type:multipart/form-data;boundary="boundary" --boundary Content-Type: text/plain; charset=ISO-2022-JPContent-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> があります。
HTTP Web 開発
[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
Merging of certain headers is in Gecko prohibited for security reasons
(injection attacks). We explicitly hard-fail the response when there is
more than one instance of Content-Length, Content-Disposition or
Location.
Content-Disposition: attachment; filename=INDEX, 1 JANUARY#30 JUNE 1916.pdf
[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
Testing from Twitter showed that the request was not being cached in other browsers. This is because some other browsers disable heuristic caching if an unrelated HTTP header, Content-Disposition, is present. Content-Disposition is a feature that allows sites to identify content for download and to suggest a name for the file to save that content to.
In comparison, Firefox legitimately treats Content-Disposition as unrelated and so does not disable heuristic caching when it is present.
multipart/form-dataは MIME とも HTTP とも異なる構文や処理方法が採られていますので、本項では区別しています。