[44] Content-Disposition: ヘッダーは、 当該実体・payload の表示・処理方法や、 表示や処理に関わるファイル名等の付加情報を指定するものです。

[50] 電子メールにおける添付ファイルや HTTP におけるダウンロードであることを指定したり、 保存時のファイル名を指定したりできます。

[106] 本ヘッダーは MIME、HTTP、SIP、multipart/form-data で使われています。

multipart/form-data は MIME とも HTTP とも異なる構文や処理方法が採られていますので、本項では区別しています。

[164] なお、ファイル名の指定については filename もあわせて参照してください。

仕様書

意味

[15] MIME では multipart/* により複数の本体部分を混合させることができますが、 それをどう表示するか、例えば添付ファイルとして表示するか、 一連の文書として埋め込んで表示するかを明示するものです >>11。

multipart/* 内の本体部分だけでなく、 メッセージ全体のヘッダーでも指定できます。

[89] HTTP では Content-Disposition: ヘッダーは応答の payload をどう処理するかの追加情報や、 payload を手元に保存する時に使うファイル名等追加のメタデータを付与するものです >>52。

[90] 要求では使用しないようです。

[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。

  1. 字句
  2. *
    1. ;
    2. 引数
[37] 字句の構文は、 MIME と HTTP で異なっています。 (字句参照。)

[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 となっています (細部に変更あり)。

[97] 引数 (MIME) を参照。非ASCII文字を使ったファイル名の符号化については、 filename も参照。なお拡張構文は MIME と HTTP で違いがあります。

[86] HTTP 送信者は、非妥当な Content-Disposition: ヘッダーを生成してはなりません >>85。

文脈

[20] Content-Disposition: は任意選択のヘッダーです >>11。

[60] このヘッダーは MIMEヘッダーであり、 MIME実体で指定できます。

[99] multipart/* の各本体部分に指定できます。 multipart/form-data の各本体部分も含まれます。

[66] また電子メール (RFC 822) メッセージのヘッダーとしても使用できます >>11。

[73] 電子メールのヘッダーで Content-Disposition: attachment が指定されている場合、そのメールは全体が添付ファイルのみを含むとみなされるようです。

[74] そのように扱われるとは RFC 2183 には明記されていませんが、 それ以外に解釈しようがありません。

[109] multipart/form-data の本体部分 >>155 や VPIM >>108 では、必須となっています。

[128] MSRP でも使用できます >>127。

[98] HTTP応答でも使用できます。

[113] SIP でも使用できます。

[123] SIP で S/MIME を使う場合、 Content-Disposition: ヘッダーは推奨です >>122。

処理モデル

[87] HTTP 受信者は、ヘッダーが非妥当な時に回復しようとしても構いません。 (妥当性検証器などでそれが望ましい動作である場合を除き) メッセージ全体を拒絶するべきではありません。 既定の動作は、無視です。 >>85

[88] MUA が非妥当な値をどう処理するべきなのかは不明です。[105] 具体的な処理については、各 disposition型と各引数の項を参照。

Disposition 型

[43] disposition型は、 Content-Disposition: ヘッダーの最初に指定する値です。 disposition型は当該実体をどうレンダリングするべきかを主として表すものです。

[34] disposition 型の種類は少なくよく定義された状態を保つことが不要な複雑化を防ぐために好ましい >>11 とされています。

[55] それでも用途の拡大によって disposition 型を追加できるよう、拡張可能とされています >>11。 disposition型を定義したら、 IANA に登録するべきshouldです >>42。

[56] MIME では私用のための x-token も認められています >>11, >>42。

[17] 認識できない disposition型は、 attachment として扱うべきshould (HTTP ではべき) です >>42, >>52。

[118] handling 引数に対応している場合、 未対応のdisposition型の場合の処理は同引数の値によります。 同引数が指定されない場合の既定値は required なので、 SIP UAS は 415 を返さなければなりません。 >>117

[119] >>118 は >>17 と矛盾しますから、 MIME や HTTP で handling 引数は実装できないこととなります。

[47] disposition型には次のものがあります。

[150] この一覧は >>149 の JSON ファイルの disposition_types にも含まれています。

[75] signed-receipt-protocol と signed-receipt-micalg は RFC 3335 を出典として IANA に登録されていましたが、 Disposition-Notification-Options: ヘッダーで使われるものとして定義されており、 Content-Disposition: ヘッダーで使われるものとして登録されたのは誤りのようです。

[76] RFC 3335 自身にも「IANA registration of the ... content disposition parameter」という記述があり、混乱しているようです。

[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型にのみ適用されると規定されているものもあります。

[130] そのようなものを Content-Type: ではなく Content-Disposition: に指定させる意図はよくわかりませんが...

既定値

[114] Content-Disposition: ヘッダーにおいて disposition型は必須ですが、 Content-Disposition: ヘッダーは指定されるとは限りません。

[115] VPIM では必須となっています。

[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。

[137] SDP 'file-disposition' では render が既定値とされています >>136。

引数

[58] 引数を定義したら、 IANA に登録するべきshouldです >>42。

[59] MIME では私用のための x-token も認められているようです >>42 が、disposition型とは違って構文上明確にはなっていません。

[16] 認識できない引数は、無視するべきshould (HTTPではべき) です >>42, >>52。

[49] 次の引数があります。

[151] この一覧は >>160 の JSON ファイルの disposition_params にも含まれています。

[8] RFC 2183 で調子に乗って色々定義しましたが、 MIME では filename 引数以外ほとんど使われていません。

[39] 構造的に似た Content-Type: ヘッダーとは異なり、 Content-Disposition: ヘッダーの引数は (特に規定がない限り) 任意の disposition型に適用できます >>42。

[27] 例えば filename 引数は attachment でも inline でも使えます >>42。

[94] MIME では、同名の引数の重複には言及がありません。

[95] HTTP では、同名の引数が複数ある場合、その Content-Disposition: ヘッダーは非妥当です >>52。

[101] ただし引数の旧来の構文と拡張構文 (例えば filename と filename*) はここでいう同名の引数には該当しないようです。

[103] HTTP では filename と filename* が指定された場合、 filename* を採用するべきです >>102。

[125] 場合によっては (MIME型などにより) 特定の引数が必須あるいは推奨されていることがあります。

それぞれの引数やMIME型の項を参照。

[143] SIP で使われる ms-proxy-2007fallback 引数は、 = と値を使わず、名前だけ指定します。

SIP でも MIME でも、このような指定は認められていません。

[157] multipart/form-data の本体部分では、 name 引数が必須です。

MIME 型依存の意味と処理モデル

multipart/*

[23] multipart/* そのものにも、含まれる実体本体にも Content-Disposition: ヘッダーを指定できます。

[28] multipart/* を参照。

[126] handling 引数においては、 全体への指定と個別の実体本体への指定の関係について特に規定があります。 場合によっては個別の実体本体への指定は無視されます。

handling を参照。

multipart/form-data

[65] multipart/form-data では特定の値のみが使われており、 他の multipart/* とは使われ方が違っています。

multipart/form-data の項をご覧ください。

multipart/related

[68] multipart/related では値は無視されます。引数は無視されません。

詳しくは multipart/related の項をご覧ください。

multipart/voice-message

[111] multipart/voice-message (VPIM) では、 disposition型が inline に固定されています。 また、含まれる実体本体の voice 引数の値について、 重複が認められないなどの制約があります。

SDP 属性

[132] SDP では、 Content-Disposition: ヘッダーに相当するものが次に示す複数の属性に対応付けられています >>131。

[142] 'file-selector' 属性の値は次の選択子で構成されます >>131。

[133] 'file-disposition' 属性の値は、disposition型です >>131。

[134] 'file-date' 属性の値は、1つ以上の引数です。 引数として次のものがあります。 >>131

[135] SDP の引数は MIME とは構文が違います。値の構文はほぼ同じです。

歴史

[145] 最初の案 (1993年6月) >>144

[4] MIME多目的インターネット・メイル拡張 (電子メイル) 系の仕様書:

  1. [1] RFC 1806
    • urn:ietf:rfc:1806
    • 実験的プロトコルとして提案されましたが、 RFC 2183 によって廃止されました。
  2. [2] RFC 2183
    • urn:ietf:rfc:2183
    • RFC 1808 の改訂版で、提案標準になりました。
  3. [3] RFC 2184
    • urn:ietf:rfc:2184
    • 引数の構文に関する更新規格です。
    • 提案標準でしたが、 RFC 2231 により廃止されました。
  4. [51] RFC 2231
    • urn:ietf:rfc:2231
    • RFC 2184 の改訂版で、引数の構文に関する RFC 2183 の更新規格です。 RFC 2184 と同じく提案標準です。

[107] RFC 2183 はなぜか RFC 1806 の更新と記載されていますが、 正誤表で廃止に修正されています >>12。 rfc-index では廃止扱い、 tools.ietf.org のデータベース上は更新兼廃止扱いになっているようです。

[48] HTTPハイパーテキスト転送プロトコル 系の仕様書:

  1. [18] I-Dインターネット原案 draft-faerber-http-content-disp-00 Use of the Content-Disposition header with HTTP
    • urn:ietf:id:draft-faerber-http-content-disp-00
    • http://ftp.ics.uci.edu/pub/ietf/http/draft-faerber-http-content-disp-00.txt
    • RFC 2068・RFC 2616 を更新することを意図していましたが、 結局 RFC 化されませんでした。
    • RFC 2183 相当の内容です。 RFC 2184 には触れていません。
  2. [53] RFC 2616 (HTTP/1.1)
    • urn:ietf:rfc:2616
    • RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2616#section-19.5.1
    • RFC 自体は原案標準ですが、 Content-Disposition の部分は参考です。
    • 制定時期にもかかわらず、 RFC 1806 相当の内容です。

HTTPハイパーテキスト転送プロトコル では特に filename 引数がよく使われているにもかかわらず、 標準化は中途半端な状況です。

[38] SIPセッション初期化プロトコル 系の仕様書:

  1. RFC 3261
    • 20.11 Content-Disposition
    • 提案標準です。
    • 前版の RFC 2543 では定義されていませんでしたが、 この版で RFC 2183 を基に規定され、積極的に用いられています。 なお、 RFC 2231 は参照していません。
  2. RFC 3968
    • SIPセッション初期化プロトコル 頭欄で使われる引数の登録簿を規定して、初期状態として Content-Disposition には handling が登録されています。

[6] RFC 2616 (HTTP/1.1) 19.5.1 Content-Disposition

[5]

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.

[9] RFC 2616 (HTTP/1.1) 15.5 Content-Disposition 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: ヘッダーの規定を削除しています。

[24] RFC 2231 / RFC 5987 の拡張構文と filename 引数における非ASCII文字のファイル名の指定については、 filename 引数の項を参照。

[22] 現実の実装では Content-Type: 欄の値, この Content-Disposition: 欄の値、それに URI のファイル名やその他の条件で、 WWW ブラウザ等はブラウザ内で表示したり保存ダイアログを出したり, どの部分をファイル名に採用するかを決めたり、云々でばらばらで混乱していますね。 (特に M$IE の場合は、版によっても挙動が変わったり、同じ版でも Windows Registry の設定で不可解に変化したりするそうです。)

[41] Content-Disposition: attachment、 filename も参照。

例

[54] 電子メイルに画像を行内表示で埋込む例:

Content-Type: multipart/mixed;
  boundary="boundary"

--boundary
Content-Type: text/plain;
  charset=ISO-2022-JP

  先日の旅行で撮った写真を送ります。
--boundary
Content-Type: image/png
Content-Transfer-Encoding: Base64
Content-Disposition: inline

... Base64 で符号化した画像データ ...
--boundary
Content-Type: text/plain;
  charset=ISO-2022-JP

  どうですか? 素敵なところでしょう?
--boundary--

レンダリング例:

  先日の旅行で撮った写真を送ります。
        +---------------------------------------+
        |                                       |
        :                 (写真)                :
        |                                       |
        +---------------------------------------+
  どうですか? 素敵なところでしょう?

[25] 電子メイルに画像を添付する例:

Content-Type: multipart/mixed;
  boundary="boundary"

--boundary
Content-Type: text/plain;
  charset=ISO-2022-JP

  先日の旅行で撮った写真を送ります。
--boundary
Content-Type: image/png
Content-Transfer-Encoding: Base64
Content-Disposition: attachment

... Base64 で符号化した画像データ ...
--boundary
Content-Type: text/plain;
  charset=ISO-2022-JP

  どうですか? 素敵なところでしょう?
--boundary--

レンダリング例:

  先日の旅行で撮った写真を送ります。                     /+----+
                                                   <<<  +-+    |
  どうですか? 素敵なところでしょう?                     | 写真 |
                                                        +------+

写真の絵にマウス・ポインタを合わせると、 写真が表示されます。 (あくまで実現の一例です。)

[26] HTML のフォームの提出の例:

<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--

[61]

Content-Disposition: file; filename=name.suffix

(HTTP応答)

出典: Lynx Users Guide v2.7.1 http://leb.net/blinux/blynx/Lynx_users_guide.html#19

[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 ながらも) 十分な品質だと思われます。

[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

[159] Re: HTTP header representation in Fetch (Honza Bambas 著, 版) https://lists.w3.org/Archives/Public/www-archive/2016Jan/0013.html

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.

[161] () https://www.legislation.gov.au/file/1916Index

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

[167] Twitter Direct Message Caching and Firefox - Mozilla Hacks - the Web developer blog () https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/

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.