[44] [DFN[[CODE(MIME)@en[Content-Disposition:]]]] [[ヘッダー]]は、当該[[実体]]・[[payload]] の表示・処理方法や、表示や処理に関わる[[ファイル名]]等の付加情報を指定するものです。 [EG[ [50] [[電子メール]]における[[添付ファイル]]や [[HTTP]] における[[ダウンロード]]であることを指定したり、保存時の[[ファイル名]]を指定したりできます。 ]EG] [106] 本[[ヘッダー]]は [[MIME]]、[[HTTP]]、[[SIP]]、[CODE(MIME)@en[[[multipart/form-data]]]] で使われています。 ;; [CODE(MIME)@en[[[multipart/form-data]]]] は [[MIME]] とも [[HTTP]] とも異なる構文や処理方法が採られていますので、本項では区別しています。 [164] なお、[[ファイル名]]の指定については [CODE(MIME)@en[filename]] もあわせて参照してください。 * 仕様書 [REFS[ - [11] '''[CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) ''' -- [42] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) - [12] [CITE[RFC Errata Report]] ([TIME[2014-10-29 05:07:24 +09:00]] 版) - [13] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) -- [85] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) -- [52] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) --- [102] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) - [14] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [122] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [124] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [108] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]] ([TIME[2014-09-07 15:46:36 +09:00]] 版) - [112] [CITE@en[RFC 3204 - MIME media types for ISUP and QSIG Objects]] ([TIME[2014-09-14 09:04:40 +09:00]] 版) - [117] [CITE@en[RFC 3204 - MIME media types for ISUP and QSIG Objects]] ([TIME[2014-09-14 09:04:40 +09:00]] 版) - [127] [CITE@en[RFC 4975 - The Message Session Relay Protocol (MSRP)]] ([TIME[2014-09-21 04:19:15 +09:00]] 版) - [141] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) -- [131] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) -- [136] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) -- [140] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) -- [138] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) -- [139] [CITE@en[RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer]] ([TIME[2014-09-13 18:22:39 +09:00]] 版) - [7] [CITE[Content Disposition Values and Parameters]] ([TIME[2014-01-30 17:45:28 +09:00]] 版) -- 旧 [CITE[MAIL CONTENT DISPOSITION Values and Parameters]] - [155] [CITE@en[RFC 7578 - Returning Values from Forms: multipart/form-data]] ([TIME[2015-07-19 23:17:07 +09:00]] 版) ]REFS] * 意味 [15] [[MIME]] では [CODE(MIME)@en[[[multipart/*]]]] により複数の[[本体部分]]を混合させることができますが、それをどう表示するか、例えば[[添付ファイル]]として表示するか、一連の文書として埋め込んで表示するかを明示するものです [SRC[>>11]]。 ;; [CODE(MIME)@en[[[multipart/*]]]] 内の[[本体部分]]だけでなく、 [[メッセージ]]全体の[[ヘッダー]]でも指定できます。 [89] [[HTTP]] では [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]は[[応答]]の [[payload]] をどう処理するかの追加情報や、 [[payload]] を手元に保存する時に使う[[ファイル名]]等追加の[[メタデータ]]を付与するものです [SRC[>>52]]。 ;; [90] [[要求]]では使用しないようです。 [91] [CODE(MIME)@en[[[multipart/form-data]]]] では[[フォーム制御子]]の名前や[[ファイル]]の名前を指定するものです。 ;; [CODE(MIME)@en[[[multipart/form-data]]]] を参照。 [92] [[SIP]] では[[本体]]に含まれるデータの解釈方法を指定するものです [SRC[>>14]]。 [104] [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]で使う[[disposition型]]や[[引数]]は拡張可能な形になっていて、 [[IANA登録簿]]がありますが、 [[MIME]] や [[HTTP]] や [[SIP]] で共有されています。ある[[プロトコル]]について定義された値が他の[[プロトコル]]でも意味を持つとは限りません [SRC[>>52]]。意味や処理方法が明確に規定されていない[[プロトコル]]で使用された際にどう処理するべきかは明記されていませんが、認識できない[[disposition型]]や[[引数]]として扱うものと解釈するのが自然でしょう。 * 構文 [45] [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]の値は、 [[disposition型]]と、零個以上の[[引数]]です。ただし各[[引数]]の前には [CODE(MIME)[[[;]]]] が必要です。 [SRC[>>11, >>52]] [36] [[disposition型]]は、[[字句]]です。[[大文字・小文字不区別]]です [SRC[>>11, >>52]]。 [FIG(railroad)[ = [[字句]] = * == [CODE(MIME)[[[;]]]] == [[引数]] ]FIG] ;; [37] [[字句]]の構文は、 [[MIME]] と [[HTTP]] で異なっています。 ([[字句]]参照。) [40] [[電子メール]]においては [CODE(MIME)[[[;]]]] の前後には[[空白]] ([[RFC 822]] でいう [CODE(ABNF)[[[linear-white-space]] / [[comment]]]]、 [[RFC 2822]]/[[RFC 5322]] でいう [CODE(ABNF)@en[[[CFWS]]]]) が挿入できると解釈されています。ただし [[MIME]] [[RFC]] ではこれは明示されていません。 [96] [[HTTP]] においては [CODE(HTTP)[[[;]]]] の前後には[[空白]] [SRC[>>52]] ([[RFC 2616]] でいう [CODE(ABNF)@en[[[LWS]]]]、[[RFC 723x]] でいう [CODE(ABNF)@en[[[OWS]]]]) が挿入できます。 [46] [[MIME]] においては[[引数]]は [[RFC 2045]] ([[字句]]と[[引用文字列]]) と [[RFC 2183]] (拡張構文) の定義が参照されています [SRC[>>11]]。ただし [[RFC 2183]] は後に改訂されて [[RFC 2231]] となっています (非互換変更は無し)。 [93] [[HTTP]] においては[[引数]]は [[RFC 2616]] ([[字句]]と[[引用文字列]]) と [[RFC 5987]] (拡張構文) の定義が参照されています [SRC[>>52]]。ただし [[RFC 2616]] は後に改訂されて [[RFC 723x]] となっています (細部に変更あり)。 ;; [97] [[引数 (MIME)]] を参照。[[非ASCII文字]]を使った[[ファイル名]]の[[符号化]]については、 [CODE(MIME)@en[[[filename]]]] も参照。なお拡張構文は [[MIME]] と [[HTTP]] で違いがあります。 [86] [[HTTP]] [[送信者]]は、[[非妥当]]な [CODE(HTTP)@en[[[Content-Disposition:]]]] [[ヘッダー]]を[[生成]]しては[['''なりません''']] [SRC[>>85]]。 * 文脈 [20] [CODE(MIME)@en[[[Content-Disposition:]]]] は[[任意選択]]の[[ヘッダー]]です [SRC[>>11]]。 [60] この[[ヘッダー]]は [[MIMEヘッダー]]であり、 [[MIME実体]]で指定できます。 [EG[ [99] [CODE(MIME)@en[[[multipart/*]]]] の各[[本体部分]]に指定できます。 [CODE(MIME)@en[[[multipart/form-data]]]] の各[[本体部分]]も含まれます。 ]EG] [66] また[[電子メール]] ([[RFC 822]]) [[メッセージ]]の[[ヘッダー]]としても使用できます [SRC[>>11]]。 [EG[ [73] [[電子メール]]の[[ヘッダー]]で [CODE(MIME)@en[[[Content-Disposition: attachment]]]] が指定されている場合、その[[メール]]は全体が[[添付ファイル]]のみを含むとみなされるようです。 ;; [74] そのように扱われるとは [[RFC 2183]] には明記されていませんが、それ以外に解釈しようがありません。 ]EG] [109] [CODE(MIME)@en[[[multipart/form-data]]]] の[[本体部分]] [SRC[>>155]] や [[VPIM]] [SRC[>>108]] では、[['''必須''']]となっています。 [128] [[MSRP]] でも使用できます [SRC[>>127]]。 [98] [[HTTP応答]]でも使用できます。 [113] [[SIP]] でも使用できます。 [123] [[SIP]] で [[S/MIME]] を使う場合、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]は[['''推奨''']]です [SRC[>>122]]。 * 処理モデル [87] [[HTTP]] [[受信者]]は、[[ヘッダー]]が[[非妥当]]な時に[[回復]]しようとしても構いません。 ([[妥当性検証器]]などでそれが望ましい動作である場合を除き) メッセージ全体を拒絶する[['''べきではありません''']]。 [[既定]]の動作は、無視です。 [SRC[>>85]] ;; [88] [[MUA]] が[[非妥当]]な値をどう処理するべきなのかは不明です。 ;; [105] 具体的な処理については、各 [[disposition型]]と各[[引数]]の項を参照。 * Disposition 型 [43] [DFN[[[disposition型]]]]は、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]の最初に指定する値です。 [[disposition型]]は当該[[実体]]をどう[[レンダリング]]するべきかを主として表すものです。 [34] disposition 型の種類は少なくよく定義された状態を保つことが不要な複雑化を防ぐために好ましい [SRC[>>11]] とされています。 [55] それでも用途の拡大によって disposition 型を追加できるよう、拡張可能とされています [SRC[>>11]]。 [[disposition型]]を定義したら、 [[IANA]] に登録する[RUBYB[べき]@en[should]]です [SRC[>>42]]。 [56] [[MIME]] では[[私用]]のための [CODE(ABNF)@en[[[x-token]]]] も認められています [SRC[>>11, >>42]]。 [17] 認識できない [[disposition型]]は、 [CODE(MIME)@en[[[attachment]]]] として扱う[RUBYB[べき]@en[should]] ([[HTTP]] では[['''べき''']]) です [SRC[>>42, >>52]]。 [118] [CODE(MIME)@en[[[handling]]]] [[引数]]に対応している場合、未対応の[[disposition型]]の場合の処理は同[[引数]]の値によります。同[[引数]]が指定されない場合の[[既定値]]は [CODE(MIME)@en[[[required]]]] なので、 [[SIP]] [[UAS]] は [CODE(HTTP)[[[415]]]] を返さなければ[['''なりません''']]。 [SRC[>>117]] ;; [119] >>118 は >>17 と矛盾しますから、 [[MIME]] や [[HTTP]] で [CODE(MIME)@en[[[handling]]]] [[引数]]は実装できないこととなります。 [47] [[disposition型]]には次のものがあります。 [FIG(list middle)[ - [CODE(MIME)@en[[[3gpp-alternative-service]]]] - [CODE(MIME)@en[[[3gpp-service-info]]]] -[CODE(MIME)[[[aib]]]] -[CODE(MIME)[[[alert]]]] -[CODE(MIME)[[[ancillary]]]] -[CODE(MIME)[[[attachment]]]] -[CODE(MIME)@en[[[by-reference]]]] -[CODE(MIME)[[[early-session]]]] -[CODE(MIME)[[[file]]]] -[CODE(MIME)@en[[[form-data]]]] -[CODE(MIME)@en[[[icon]]]] -[CODE(MIME)@en[[[info-package]]]] -[CODE(MIME)@en[[[inline]]]] -[CODE(MIME)@en[[[notification]]]] - [CODE(MIME)@en[[[process]]]] -[CODE(MIME)@en[[[recipient-list]]]] -[CODE(MIME)@en[[[recipient-list-history]]]] - [CODE(MIME)@en[[[recording-session]]]] -[CODE(MIME)[[[render]]]] -[CODE(MIME)[[[session]]]] -[CODE(MIME)[[[signal]]]] -[CODE(MIME)[[[signed-receipt-protocol]]]] -[CODE(MIME)[[[signed-receipt-micalg]]]] ]FIG] [150] この一覧は >>149 の [[JSON]] [[ファイル]]の [CODE[disposition_types]] にも含まれています。 [REFS[ - [149] [CITE@en[data-web-defs/headers.txt at master · manakai/data-web-defs]] ([TIME[2014-11-03 08:05:38 +09:00]] 版) ]REFS] [75] [CODE(MIME)@en[[[signed-receipt-protocol]]]] と [CODE(MIME)@en[[[signed-receipt-micalg]]]] は [[RFC 3335]] を出典として [[IANA]] に登録されていましたが、 [CODE(822)@en[[[Disposition-Notification-Options:]]]] [[ヘッダー]]で使われるものとして定義されており、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]で使われるものとして登録されたのは誤りのようです。 ;; [76] [[RFC 3335]] 自身にも「IANA registration of the ... content disposition parameter」という記述があり、混乱しているようです。 [84] これらは2012年6月8日付けの [[IANA登録簿]] (2012年6月2日時点) [SRC[>>77]] にはまだ含まれていますが、2012年9月18日付け (2013年1月15日時点) [SRC[>>78]] では削除されています。 [REFS[ - [77] - [78] ]REFS] [156] [CODE(MIME)@en[[[multipart/form-data]]]] の[[本体部分]]では、 [CODE(MIME)@en[[[form-data]]]] でなければ[['''なりません''']] [SRC[>>155]]。 [110] [[VPIM]] において[[音声]]はすべて [CODE(MIME)@en[[[inline]]]] を指定する必要があります [SRC[>>108]]。 [129] [CODE[3gpp-*]] のように特定の [[MIME型]]にのみ適用されると規定されているものもあります。 ;; [130] そのようなものを [CODE(MIME)@en[[[Content-Type:]]]] ではなく [CODE(MIME)@en[[[Content-Disposition:]]]] に指定させる意図はよくわかりませんが... ** 既定値 [114] [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]において [[disposition型]]は必須ですが、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]は指定されるとは限りません。 ;; [115] [[VPIM]] では必須となっています。 [30] [[MUA]] は、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]が無い場合、適当な方法で表示して構いません [SRC[>>11]]。 [100] [[HTTP]] では [CODE(HTTP)@en[[[Content-Disposition:]]]] [[ヘッダー]]が無い場合の解釈は明記されていませんが、 [CODE(HTTP)@en[[[Content-Disposition: inline]]]] は「[[既定]]の処理」を表す [SRC[>>52]] とされており、無指定と [CODE(HTTP)@en[[[inline]]]] は等価ということになります。 [120] [[SIP]] では、[[既定]]の[[disposition型]]は [CODE(MIME)@en[[[render]]]] です [SRC[>>14]]。 [121] [CODE(MIME)@en[[[application/sdp]]]] では、既定の[[disposition型]]は [CODE(MIME)@en[[[session]]]] です [SRC[>>14]]。 [116] [[ISUP]] ([CODE(MIME)@en[[[application/isup]]]]) / [[QSIG]] ([CODE(MIME)@en[[[application/qsig]]]]) では、[[既定]]の [[disposition型]]は [CODE(MIME)@en[[[signal]]]] です [SRC[>>112]]。 [137] [[SDP]] [CODE@en[[['file-disposition']]]] では [CODE(MIME)@en[[[render]]]] が[[既定値]]とされています [SRC[>>136]]。 * 引数 [58] [[引数]]を定義したら、 [[IANA]] に登録する[RUBYB[べき]@en[should]]です [SRC[>>42]]。 [59] [[MIME]] では[[私用]]のための [CODE(ABNF)@en[[[x-token]]]] も認められているようです [SRC[>>42]] が、[[disposition型]]とは違って構文上明確にはなっていません。 [16] 認識できない[[引数]]は、無視する[RUBYB[べき]@en[should]] ([[HTTP]]では[['''べき''']]) です [SRC[>>42, >>52]]。 [49] 次の[[引数]]があります。 [FIG(list short)[ -[CODE(MIME)[[[alternates]]]] -[CODE(MIME)[[[creation-date]]]] -[CODE(MIME)[[[device]]]] -[CODE(MIME)[[[filename]]]] -[CODE(MIME)[[[handling]]]] -[CODE(MIME)[[[modification-date]]]] -[CODE(MIME)[[[name]]]] - [CODE(MIME)@en[preview-type]] - [CODE(MIME)@en[[[program]]]] - [CODE(MIME)@en[[[ms-proxy-2007fallback]]]] -[CODE(MIME)[[[read-date]]]] -[CODE(MIME)[[[size]]]] -[CODE(MIME)[[[voice]]]] ]FIG] [151] この一覧は >>160 の [[JSON]] [[ファイル]]の [CODE[disposition_params]] にも含まれています。 [REFS[ - [160] [CITE@en[data-web-defs/headers.json at master · manakai/data-web-defs]] ([TIME[2016-03-29 23:53:24 +09:00]] 版) -- [152] ドキュメント [CITE@en[data-web-defs/headers.txt at master · manakai/data-web-defs]] ([TIME[2014-11-03 08:05:38 +09:00]] 版) ]REFS] [8] [[RFC 2183]] で調子に乗って色々定義しましたが、 [[MIME]] では [CODE(MIME)[filename]] 引数以外ほとんど使われていません。 [39] 構造的に似た [CODE(MIME)[[[Content-Type:]]]] [[ヘッダー]]とは異なり、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]の[[引数]]は (特に規定がない限り) 任意の [[disposition型]]に適用できます [SRC[>>42]]。 [EG[ [27] 例えば [CODE(MIME)@en[[[filename]]]] [[引数]]は [CODE(MIME)@en[[[attachment]]]] でも [CODE(MIME)@en[[[inline]]]] でも使えます [SRC[>>42]]。 ]EG] [94] [[MIME]] では、同名の[[引数]]の重複には言及がありません。 [95] [[HTTP]] では、同名の[[引数]]が複数ある場合、その [CODE(HTTP)@en[[[Content-Disposition:]]]] [[ヘッダー]]は[[非妥当]]です [SRC[>>52]]。 [101] ただし[[引数]]の旧来の構文と拡張構文 (例えば [CODE(HTTP)[[[filename]]]] と [CODE(HTTP)[[[filename*]]]]) はここでいう同名の[[引数]]には該当しないようです。 [103] [[HTTP]] では [CODE(HTTP)@en[[[filename]]]] と [CODE(HTTP)@en[[[filename*]]]] が指定された場合、 [CODE(HTTP)@en[[[filename*]]]] を採用する[['''べきです''']] [SRC[>>102]]。 [125] 場合によっては ([[MIME型]]などにより) 特定の[[引数]]が[[必須]]あるいは[[推奨]]されていることがあります。 ;; それぞれの[[引数]]や[[MIME型]]の項を参照。 [143] [[SIP]] で使われる [CODE(MIME)@en[[[ms-proxy-2007fallback]]]] [[引数]]は、 [CODE[[[=]]]] と値を使わず、名前だけ指定します。 ;; [[SIP]] でも [[MIME]] でも、このような指定は認められていません。 [157] [CODE(MIME)@en[[[multipart/form-data]]]] の[[本体部分]]では、 [CODE(MIME)@en[[[name]]]] [[引数]]が必須です。 * MIME 型依存の意味と処理モデル ** [CODE(MIME)@en[multipart/[VAR[*]]]] [23] [CODE(MIME)@en[[[multipart/*]]]] そのものにも、含まれる[[実体本体]]にも [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]を指定できます。 ;; [28] [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] を参照。 [126] [CODE(MIME)@en[[[handling]]]] [[引数]]においては、全体への指定と個別の[[実体本体]]への指定の関係について特に規定があります。場合によっては個別の[[実体本体]]への指定は無視されます。 ;; [CODE(MIME)@en[[[handling]]]] を参照。 ** [CODE(MIME)@en[multipart/form-data]] [65] [CODE(MIME)@en[[[multipart/form-data]]]] では特定の値のみが使われており、他の [CODE(MIME)@en[[[multipart/*]]]] とは使われ方が違っています。 ;; [CODE(MIME)@en[[[multipart/form-data]]]] の項をご覧ください。 ** [CODE(MIME)@en[multipart/related]] [68] [CODE(MIME)@en[[[multipart/related]]]] では値は無視されます。[[引数]]は無視されません。 ;; 詳しくは [CODE(MIME)@en[[[multipart/related]]]] の項をご覧ください。 ** [CODE(MIME)@en[multipart/voice-message]] [111] [CODE(MIME)@en[[[multipart/voice-message]]]] ([[VPIM]]) では、 [[disposition型]]が [CODE(MIME)@en[[[inline]]]] に固定されています。また、含まれる[[実体本体]]の [CODE(MIME)@en[[[voice]]]] [[引数]]の値について、重複が認められないなどの制約があります。 * SDP 属性 [132] [[SDP]] では、 [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]に相当するものが次に示す複数の[[属性]]に対応付けられています [SRC[>>131]]。 [FIG(short list)[ - [CODE[[['file-selector']]]] - [CODE[[['file-disposition']]]] - [CODE[[['file-date']]]] ]FIG] [142] [DFN[[CODE[[['file-selector']]]]]] [[属性]]の値は次の[[選択子]]で構成されます [SRC[>>131]]。 [FIG(short list)[ - [CODE[[['name']]]] - [CODE[[['size']]]] ]FIG] [133] [DFN[[CODE[[['file-disposition']]]]]] [[属性]]の値は、[[disposition型]]です [SRC[>>131]]。 [134] [DFN[[CODE[[['file-date']]]]]] [[属性]]の値は、1つ以上の[[引数]]です。 [[引数]]として次のものがあります。 [SRC[>>131]] [FIG(short list)[ - [CODE[[['creation']]]] - [CODE[[['modification']]]] - [CODE[[['read']]]] ]FIG] ;; [135] [[SDP]] の[[引数]]は [[MIME]] とは構文が違います。値の構文はほぼ同じです。 * 歴史 [145] 最初の案 (1993年6月) [SRC[>>144]] [REFS[ - [144] [CITE[Content-Disposition Header]] ([TIME[2003-01-07 07:00:00 +09:00]] 版) ]REFS] [4] [ABBR[MIME] [多目的インターネット・メイル拡張]] ([[電子メイル]]) 系の仕様書: = [1] [[RFC 1806]] -- -- [[実験的]]プロトコルとして提案されましたが、 RFC 2183 によって[[廃止]]されました。 = [2] [[RFC 2183]] -- -- RFC 1808 の改訂版で、[[提案標準]]になりました。 = [3] [[RFC 2184]] -- -- 引数の構文に関する[[更新]]規格です。 -- 提案標準でしたが、 RFC 2231 により廃止されました。 = [51] [[RFC 2231]] -- -- RFC 2184 の改訂版で、引数の構文に関する RFC 2183 の更新規格です。 RFC 2184 と同じく提案標準です。 [107] [[RFC 2183]] はなぜか [[RFC 1806]] の[[更新]]と記載されていますが、 [[正誤表]]で[[廃止]]に修正されています [SRC[>>12]]。 [[rfc-index]] では[[廃止]]扱い、 [[tools.ietf.org]] のデータベース上は[[更新]]兼[[廃止]]扱いになっているようです。 [TIME[2014-11-03T01:41:27.100Z]] [48] [ABBR[HTTP] [ハイパーテキスト転送プロトコル]] 系の仕様書: = [18] [ABBR[[[I-D]]] [インターネット原案]] [[draft-faerber-http-content-disp-00]] [CITE[Use of the Content-Disposition header with HTTP]] -- -- -- [[RFC 2068]]・RFC 2616 を更新することを意図していましたが、結局 RFC 化されませんでした。 -- RFC 2183 相当の内容です。 RFC 2184 には触れていません。 = [53] [[RFC 2616]] ([[HTTP/1.1]]) -- -- [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2014-09-07 04:14:53 +09:00]] 版) -- RFC 自体は[[原案標準]]ですが、 [CODE(HTTP)[Content-Disposition]] の部分は参考です。 -- 制定時期にもかかわらず、 RFC 1806 相当の内容です。 [ABBR[HTTP] [ハイパーテキスト転送プロトコル]] では特に [CODE(MIME)[[[filename]]]] 引数がよく使われているにもかかわらず、標準化は中途半端な状況です。 [38] [ABBR[SIP] [セッション初期化プロトコル]] 系の仕様書: = [[RFC 3261]] -- [CITE[20.11 Content-Disposition]] -- 提案標準です。 -- 前版の [[RFC 2543]] では定義されていませんでしたが、この版で RFC 2183 を基に規定され、積極的に用いられています。なお、 RFC 2231 は参照していません。 = [[RFC 3968]] -- [ABBR[SIP] [セッション初期化プロトコル]] 頭欄で使われる引数の登録簿を規定して、初期状態として [CODE(SIP)[Content-Disposition]] には [CODE(SIP)[handling]] が登録されています。 [FIG(quote)[ [FIGCAPTION[ [6] RFC 2616 (HTTP/1.1) 19.5.1 Content-Disposition ]FIGCAPTION] [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]. [CODE(HTTP)[Content-Disposition]] [[応答頭欄]]は、 [[利用者]]が[[内容]]を[[ファイル]]に保存する場合の既定の[[ファイル名]]を[[起源鯖]]が提案するための手段として提案されています。この使用は [[RFC1806]] の [CODE(MIME)[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. 現時点では [CODE(ABNF)[filename-parm]] 引数だけが HTTP 実装に適用されると信じられていますが、受信した[[利用者エージェント]]は、 [CODE(ABNF)[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. この頭が[[応答]]で [CODE(MIME)[[[application/octet-stream]]]] [[内容型]]と共に使われている場合は、利用者エージェントは応答を表示するべきではなく、「応答を保存・・・」対話に直接入るべきであることを暗に提案しています。 > See section 15.5 for Content-Disposition security issues. ]FIG] [REFS[ - [153] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2014-09-07 04:14:53 +09:00]] 版) ]REFS] [FIG(quote)[ [FIGCAPTION[ [9] RFC 2616 (HTTP/1.1) 15.5 Content-Disposition Issues ]FIGCAPTION] > 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]] でしばしば実装される [CODE(HTTP)[Content-Disposition]] 頭は [[RFC 1806]] から派生したものですが、 RFC 1806 には多くの非常に深刻な安全上の問題があります。 [CODE(HTTP)[Content-Disposition]] は HTTP 規格の一部ではありませんが、広く実装されていることから、その使用と危険を実装者のために文章化しています。詳しくは (RFC 1806 を更新する) [[RFC 2183]] をご覧下さい。 ]FIG] [10] [[RFC 2616]] の改訂である [[RFC 7231]] は、 [[RFC 6266]] で規定されているとして [CODE(HTTP)@en[[[Content-Disposition:]]]] [[ヘッダー]]の規定を削除しています。 ;; [24] [[RFC 2231]] / [[RFC 5987]] の拡張構文と [CODE(MIME)@en[[[filename]]]] [[引数]]における[[非ASCII文字]]の[[ファイル名]]の指定については、 [CODE(MIME)@en[[[filename]]]] [[引数]]の項を参照。 [22] 現実の実装では [[Content-Type:]] 欄の値, この [CODE[Content-Disposition:]] 欄の値、それに [[URI]] のファイル名やその他の条件で、 [[WWW]] ブラウザ等はブラウザ内で表示したり保存ダイアログを出したり, どの部分をファイル名に採用するかを決めたり、云々でばらばらで混乱していますね。 (特に [[M$IE]] の場合は、版によっても挙動が変わったり、同じ版でも Windows Registry の設定で不可解に変化したりするそうです。) ;; [41] [CODE(MIME)@en[[[Content-Disposition: attachment]]]]、 [CODE(MIME)@en[[[filename]]]] も参照。 * 例 [54] 電子メイルに画像を[[行内]]表示で埋込む例: [PRE(822)[ [CODE(MIME)[[[Content-Type]]]]: [CODE(MIME)[[[multipart/mixed]]]]; [CODE(MIME)[[[boundary]]]]="boundary" --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[text/plain]]]]; [CODE(MIME)[[[charset]]]]=[CODE(charset)[[[ISO-2022-JP]]]] 先日の旅行で撮った写真を送ります。 --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[image/png]]]] [CODE(MIME)[[[Content-Transfer-Encoding]]]]: [CODE(MIME)[[[Base64]]]] [CODE(MIME)[[[Content-Disposition]]]]: [CODE(MIME)[[[inline]]]] [VAR[... Base64 で符号化した画像データ ...]] --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[text/plain]]]]; [CODE(MIME)[[[charset]]]]=[CODE(charset)[[[ISO-2022-JP]]]] どうですか? 素敵なところでしょう? --boundary-- ]PRE] レンダリング例: [PRE[ 先日の旅行で撮った写真を送ります。 +---------------------------------------+ | | : (写真) : | | +---------------------------------------+ どうですか? 素敵なところでしょう? ]PRE] [25] 電子メイルに画像を[[添付]]する例: [PRE(822)[ [CODE(MIME)[[[Content-Type]]]]: [CODE(MIME)[[[multipart/mixed]]]]; [CODE(MIME)[[[boundary]]]]="boundary" --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[text/plain]]]]; [CODE(MIME)[[[charset]]]]=[CODE(charset)[[[ISO-2022-JP]]]] 先日の旅行で撮った写真を送ります。 --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[image/png]]]] [CODE(MIME)[[[Content-Transfer-Encoding]]]]: [CODE(MIME)[[[Base64]]]] [CODE(MIME)[[[Content-Disposition]]]]: [CODE(MIME)[[[attachment]]]] [VAR[... Base64 で符号化した画像データ ...]] --boundary [CODE(MIME)[Content-Type]]: [CODE(MIME)[[[text/plain]]]]; [CODE(MIME)[[[charset]]]]=[CODE(charset)[[[ISO-2022-JP]]]] どうですか? 素敵なところでしょう? --boundary-- ]PRE] レンダリング例: [PRE[ 先日の旅行で撮った写真を送ります。 /+----+ <<< +-+ | どうですか? 素敵なところでしょう? | 写真 | +------+ ]PRE] [Q[写真]]の絵にマウス・ポインタを合わせると、写真が表示されます。 [WEAK[(あくまで実現の一例です。)]] [26] [[HTML]] の[[フォーム]]の[[提出]]の例: [PRE(HTML)[ <[CODE(HTMLe)[[[form]]]] [CODE(HTMLa)[[[enctype]]]]="[CODE(MIME)[[[multipart/form-data]]]]"> <[CODE(HTMLe)[[[dl]]]]> <[CODE(HTMLe)[[[dt]]]]>名前 <[CODE(HTMLe)[[[dd]]]]> <[CODE(HTMLe)[[[input]]]] [CODE(HTMLa)[[[type]]]]="text" [CODE(HTMLa)[[[name]]]]="usrname" [CODE(HTMLa)[[[value]]]]="名無しさん" /> <[CODE(HTMLe)[[[dt]]]]><[CODE(HTMLe)[input]] [CODE(HTMLa)[type]]="[[submit]]" /> ]PRE] このフォームから提出すると: [PRE(MIME)[ [CODE(MIME)[Content-Type]]: [CODE(MIME)[multipart/form-data]]; [CODE(MIME)[boundary]]="boundary" --boundary Content-Type: text/plain; charset=[CODE(charset)[ISO-2022-JP]] Content-Disposition: [[form-data]]; [[name]]="usrname" 名無しさん --boundary-- ]PRE] [61] [PRE(HTTP example code)[ Content-Disposition: file; filename=name.suffix ]PRE] ([[HTTP]][[応答]]) ;; 出典: [CITE[Lynx Users Guide v2.7.1]] [148] >>146 と >>147 には、 [CODE(MIME)@en[[[Content-Disposition:]] mixed]] を指定した [CODE(MIME)@en[[[multipart/*]]]] [[実体]]の例が示されています。 >>146 は [CODE(MIME)@en[[[multipart/form-data]]]] の [CODE(MIME)@en[form-data]] を [CODE(MIME)@en[mixed]] に置き換えたと思われ、 [CODE(MIME)@en[[[name]]]] [[引数]]も指定されています。 [REFS[ - [146] [CITE[「一次エネルギー消費量算定用プログラム(建築物用)」計算 API 仕様(案)]] ([TIME[2014-06-24 23:18:06 +09:00]] 版) - [147] [CITE[gist:11038105]] ([TIME[2014-11-03 07:55:39 +09:00]] 版) ]REFS] * 関連 [80] [[ダウンロード]]の動作を制御する[[プロトコル要素]]としては、 [CODE(HTTP)@en[[[X-MS-InvokeApp:]]]], [CODE(HTML)@en[[[DownloadOptions]]]], [CODE(HTTP)@en[[[X-Download-Options:]]]], [CODE(HTML)@en[<[[a]] [[download]]>]] があります。 * メモ [FIG(amazon)[ HTTP Web 開発 ]FIG] [19] [CODE[Content-Disposition:]] 欄は、 HTTP でも (特に [[CGI]] script の類で) よく使われるにも拘らず、 HTTP Core 仕様書は簡単に触れるにとどまっています。 >>18 は RFC 2184 及び現実の使用状況・ HTTP の仕様をそれなりに折り合わせたもので、実装の指針としては (期限切れ I-D ながらも) 十分な品質だと思われます。 - [21] >>19 ただし、 >>20 のような問題には触れていませんから、もちろんこの I-D に従って実装すれば良いというものでもありません。 - [29] Referer とか「注目の WikiPage」ランキングみてると、実は [CODE[Content-Disposition]] 欄ってすごい人気ですね。やっぱり「[[HTTP]] で[[ダウンロード]]させる[[ファイル名]]を指定する方法」として有名だからかな? - [31] >>29 [[とほほ]]とか [[CGI-ML]] とか [[Web相談室]]とかが普及に貢献してますから(w - [32] それにしても、 HTTP 用のこの欄が標準化されないのはすごく謎。他の MIME 由来欄はちゃんと標準化してるのに。特にファイル名の非 ASCII 文字の問題 ([[encoded-word]] or [[RFC 2231]] or 生) という大問題があるから、 MIME 任せには出来ないと思うんだけど。 (2231 実装している HTTP UA なんてあるんだろうか?) - [33] [WEAK[2003-08-29 11:41:24 +00:00]] ''[[attachment]]'': >>29 この WikiPage は [[Google]] で日本語11位にランクインしてますから(藁 [57] などで検索してみるとひどい状況。仕様書がひどくて実装もひどけりゃウェブの文書もひどくなるのは至極当然。そうはいっても、 Google 上位サイトで仕様書を参照しているサイトはどれだけあります? 参照して無くても、読んだことがありそうな人が書いてる文書はどれだけあります? この分野全般について言えることですけど、わかりやすくて正しい解説書・解説サイトがほぼ皆無というのも問題かも。 ([[名無しさん]] [WEAK[2005-01-19 08:48:15 +00:00]]) [62] [CITE@ja[JVN#95019167: Internet Explorer における MHTML によるダウンロードのダイアログボックス回避の脆弱性]] ([CODE[2007-06-21 17:52:08 +09:00]] 版) ([[名無しさん]] [WEAK[2007-06-24 07:41:31 +00:00]]) [63] [CITE@ja[JVN#27203006: Internet Explorer における MHTML により任意のスクリプトが実行される脆弱性]] ([CODE[2007-06-21 17:52:08 +09:00]] 版) ([[名無しさん]] [WEAK[2007-06-24 07:42:16 +00:00]]) [64] [CITE[Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding]] ([TIME[2008-09-21 02:53:50 +09:00]] 版) [67] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]] ([TIME[2009-09-12 07:37:40 +09:00]] 版) [69] [CITE[Test Cases for HTTP Content-Disposition header field and the Encodings defined in RFC 2047/6266 and RFC 2231/5987]] ( ([TIME[2011-08-03 23:43:34 +09:00]] 版)) [70] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ( ([TIME[2012-03-02 10:21:42 +09:00]] 版)) [71] [CITE[Test Cases for HTTP Content-Disposition header field (RFC 6266) and the Encodings defined in RFCs 2047, 2231 and 5987]] ( ([TIME[2012-03-06 16:55:36 +09:00]] 版)) [72] [CITE[Content-Disposition FireFoxとIEの挙動の違い - 開発者の談話室]] ( ([TIME[2010-07-29 15:43:38 +09:00]] 版)) [79] [CITE@en[RFC 4975 - The Message Session Relay Protocol (MSRP)]] ( ([TIME[2012-02-26 13:20:50 +09:00]] 版)) [81] [CITE@en[RFC 5438 - Instant Message Disposition Notification (IMDN)]] ( ([TIME[2013-10-06 10:18:10 +09:00]] 版)) [82] [CITE[IE9以降でもHTMLフォームでファイル名とファイルの中身を外部から指定できる | 徳丸浩の日記]] ( ([TIME[2014-01-30 01:06:48 +09:00]] 版)) [83] [CITE@en[RFC 5621 - Message Body Handling in the Session Initiation Protocol (SIP)]] ( ([TIME[2014-06-09 06:12:50 +09:00]] 版)) [416] [CITE@ja[The Return of the Content-Disposition Vulnerability in IE | セキュリティ情報 | 株式会社ラック]] ( ([TIME[2014-11-03 07:51:13 +09:00]] 版)) [417] [CITE@en[Microsoft Internet Explorer Content-Disposition Header Handling Information Disclosure Vulnerability]] ( ([TIME[2014-11-03 07:52:11 +09:00]] 版)) [418] [CITE@en[Microsoft Outlook Express Content Disposition Parsing Information Disclosure Vulnerability | Symantec]] ( ([TIME[2014-11-03 07:59:54 +09:00]] 版)) [154] [CITE[Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting]] ([TIME[2015-03-31 16:46:16 +09:00]] 版) [158] [CITE@en[655389 – CRLF Injection and the parsing of HTTP headers]] ([TIME[2015-10-05 20:57:53 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [159] [CITE@en[Re: HTTP header representation in Fetch]] ([[Honza Bambas]] 著, [TIME[2016-01-20 05:16:55 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [161] ([TIME[2016-07-23 19:35:49 +09:00]]) ]FIGCAPTION] > Content-Disposition: attachment; filename=INDEX, 1 JANUARY#30 JUNE 1916.pdf ]FIG] [162] >>161 [[Firefox]] では[[ダウンロード]]になりますが、 [[Chrome]] では[[ネットワークエラー]]になります。 [TIME[2016-07-23T10:37:43.700Z]] [163] [CITE@en[Preventing some CRLF header injection attacks · Issue #375 · whatwg/fetch]] ([TIME[2016-08-25 12:05:52 +09:00]]) [165] [CITE@en[Clarify package data algorithm for FormData]] ([[eehakkin]]著, [TIME[2016-12-17 01:36:13 +09:00]]) [166] [CITE[ Proposed addition of Content-Disposition to HTTP 1.1 spec]] ([TIME[1996-03-29 07:28:05 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [167] [CITE@en-US[Twitter Direct Message Caching and Firefox - Mozilla Hacks - the Web developer blog]] ([TIME[2020-04-06 17:58:47 +09:00]]) ]FIGCAPTION] > 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. ]FIG]