ハイパーテキスト転送プロトコル (HTTP) における Content-Disposition ヘッダーフィールド の使用

以下は [RFC2616] で定義されています:

  token         = <token, defined in [RFC2616], Section 2.2>
  quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
  value         = <value, defined in [RFC2616], Section 3.6>
                ; token | quoted-string
              

以下は [RFC5987] で定義されています:

  ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

同一のパラメータ名が複数回現れる Content-Disposition ヘッダーフィールド値は無効です。

また、暗黙の線形空白の規則（RFC2616 Section 2.1）により、単語（token または quoted-string）と区切り文字の間に任意の空白が現れてもよいことに注意してください。

さらに、ext-value で使用される形式は自然言語（例えば "en"）を指定することを許しますが、これはファイル名に対しては限定的な有用性があり、受信者によって無視される可能性が高いことに注意してください。

ディスポジションの種類が "attachment"（大文字小文字を区別しない）に一致する場合、受信者は通常の処理（メディアタイプに従う処理）ではなく、ユーザーにローカルに保存するよう促すべきであることを示します。

一方、"inline" に一致する場合は既定の処理を意味します。従って、"inline" はファイル名などの追加パラメータで拡張される場合にのみ有用です。

不明または未処理のディスポジション種類は、受信者が "attachment" と同様に扱うべきです SHOULD（関連: [RFC2183] Section 2.8）。

"filename" および "filename*" パラメータ（大文字小文字を区別しない一致）は、メッセージペイロードを保存する際に使用するファイル名を構築する方法に関する情報を提供します。

ディスポジションの種類に応じて、この情報は直ちに使用される場合があります（"attachment" による "名前を付けて保存" 対話の際など）、または後で使用される場合があります（例えば、ユーザーが現在表示中のページの内容を保存することを決めたときなど）。

"filename" と "filename*" の違いは、"filename*" が [RFC5987] で定義されたエンコーディングを使用し、ISO-8859-1 に含まれない文字を利用できる点です。

多くの既存 UA は本仕様より前に実装されており "filename*" を理解しません。したがって、単一のヘッダーフィールド値に "filename" と "filename*" の両方が含まれている場合、受信者は "filename*" を選び "filename" を無視することを SHOULD 推奨します。これにより、送信者はより表現力のある "filename*" と、レガシー受信者向けのフォールバックとしての "filename" を同時に送ることができます（例は Section 5 を参照）。

受信者は指定されたファイル名を助言的なものとして扱うべきであり、抽出する際には非常に注意を払う必要があります。特に:

• 受信者はファイルシステム上で明示的に許可された場所以外に書き込みができないようにしなければなりません MUST NOT。例えば "/etc/passwd" のような既知のシステム領域を上書きできないようにする必要があります。一つの戦略は、filename パラメータのフォルダ名情報を信用せず、最後のパスセグメントのみを取り出して実際のファイル名だけを考慮することです（'パスセグメント' は "\" や "/" による区切りで定義されます）。

• 多くのプラットフォームはファイルシステムでの型情報をインターネットメディアタイプではなくファイル拡張子に依存しています。サーバー提供の拡張子をそのまま信用すると、保存後にファイルを開く際に特権昇格を招く可能性があります（例: ".exe"）。したがって、拡張子でメディアタイプを決める受信者は、受信したペイロードのメディアタイプに最適に一致する安全な拡張子を使用するようにする必要があります MUST。

• 受信者はユーザーインターフェースやファイル名で混乱を引き起こす既知の文字列（制御文字や先頭・末尾の空白など）を除去または置換することを SHOULD 推奨します。

• ファイルシステムやシェルコマンドで特別な意味を持つ名前（"."、".."、"~"、"|"、デバイス名など）についても注意が必要です。受信者はそのような名前を無視または置換することを SHOULD 推奨します。

将来の拡張を可能にするため、受信者は未認識のパラメータを無視することを SHOULD 推奨します（関連: [RFC2183] Section 2.8）。

RFC2183 Section 9 は、ディスポジション種類とディスポジションパラメータのための IANA レジストリを定義していることに注意してください。このレジストリは MIME や HTTP のように Content-Disposition を使用する複数のプロトコルで共有されます。したがって、登録されたすべての値が HTTP の文脈で意味を持つとは限りません。

本仕様は、RFC2183 Section 9 で定義されたディスポジション値およびパラメータの登録手順に変更を導入しません。

本文書は恒久的な HTTP ヘッダーフィールドレジストリ（[RFC3864] 参照）における Content-Disposition HTTP ヘッダーフィールドの定義を更新します。

Header field name:

Content-Disposition

Applicable protocol:

http

Status:

standard

Author/Change controller:

IETF

Specification document:

this specification (Section 4)

Related information:

none

10.1. 規範的参考文献

[ISO-8859-1]

International Organization for Standardization, “Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1”, ISO/IEC 8859-1:1998, 1998.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

[RFC5987]

Reschke, J., “Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters”, RFC 5987, August 2010.

10.2. 参考情報

[RFC2046]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.

[RFC2047]

Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”, RFC 2047, November 1996.

[RFC2183]

Troost, R., Dorner, S., and K. Moore, Ed., “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field”, RFC 2183, August 1997.

[RFC2231]

Freed, N. and K. Moore, “MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations”, RFC 2231, November 1997.

[RFC2388]

Masinter, L., “Returning Values from Forms: multipart/form-data”, RFC 2388, August 1998.

[RFC3864]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, RFC 3864, September 2004.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, January 2005.

[US-ASCII]

American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange”, ANSI X3.4, 1986.

'encoded-word' は 'quoted-string' 内に現れてはなりません。

...

'encoded-word' は MIME Content-Type や Content-Disposition のパラメータ、または構造化フィールド本文では 'comment' や 'phrase' 以外の場所で使ってはならない。

実際には、一部の UA はこのエンコーディングを実装し、一部は実装せず（エンコード文字列をユーザーに露呈）、一部は混乱します。

一部の UA はパーセントエンコーディング（RFC3986 Section 2.1）を受け入れます。デコードに使われる文字エンコーディングは、参照ページのエンコーディング、UA のロケール、設定、パラメータ値など複数の要因に依存します。

実際には、これをサポートしない UA はエスケープされた文字列をそのまま表示し、サポートする UA でも期待される文字エンコーディングが予測困難なため、使いにくい手法です。

一部の UA は値（quoted-string 形式のデフォルトは ISO-8859-1）を検査し、UTF-8 の方が正しいと判断される場合に UTF-8 に切り替えます。

上記のアプローチと同様に、相互運用性がなく、実際の値を誤解釈するリスクがあります。