1. 序論 (Introduction)

RFC 2616はContent-Dispositionレスポンスヘッダーフィールド (Response Header Field) ([RFC2616]のセクション19.5.1) を定義していますが、これはHTTP/1.1標準の一部ではないと指摘しています (セクション15.5):

Content-DispositionはHTTP標準の一部ではありませんが、広く実装されているため、実装者のためにその使用法とリスクを文書化しています。

本仕様はHTTPで使用されるContent-Dispositionの定義と登録を引き継ぎます。既存のユーザーエージェント (User Agent, UA) との相互運用性テストに基づいて、多目的インターネットメール拡張 (Multipurpose Internet Mail Extensions, MIME) バリアント ([RFC2183]) で定義されているヘッダーフィールドの機能のプロファイル (Profile) を完全に定義し、また国際化の側面を明確にします。

注記: 本文書は、HTTPを介して送信されるペイロード本体 (Payload Body) 内に出現するContent-Dispositionヘッダーフィールドには適用されません。例えば、メディアタイプ (Media Type) "multipart/form-data" ([RFC2388]) を使用する場合などです。

2. 表記法 (Notational Conventions)

本文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、及び "OPTIONAL" は、[RFC2119]に記載されているとおりに解釈されるものとします。

MUST / MUST NOT: しなければならない / してはならない
REQUIRED: 必須である
SHALL / SHALL NOT: しなければならない / してはならない
SHOULD / SHOULD NOT: すべきである / すべきでない
RECOMMENDED: 推奨される
MAY: してもよい
OPTIONAL: 任意である

本仕様は、[RFC2616]のセクション2.1で定義されている拡張BNF (Augmented BNF, ABNF) 表記法を使用します。これには、暗黙的な線形空白 (Linear Whitespace, LWS) の規則が含まれます。

3. 適合性とエラー処理 (Conformance and Error Handling)

本仕様は、Content-Dispositionヘッダーフィールドの送信者 (通常はHTTPオリジンサーバー (Origin Server)) と受信者 (通常はHTTPユーザーエージェント (User Agent)) の両方に対する適合性基準を定義します。実装がその役割に関連するすべての要件に準拠している場合、その実装は適合しているとみなされます。

本仕様は、ABNFと散文による要件 (セクション4) の両方を使用して、ヘッダーフィールド値の特定の形式を無効と定義しますが、これらの無効なフィールド値の特別な処理は定義しません。

送信者は無効なContent-Dispositionヘッダーフィールドを生成してはなりません (MUST NOT)。

受信者は無効なヘッダーフィールドから使用可能なフィールド値を回復するための措置を講じてもよい (MAY) ですが、これが明示的に望ましい動作である場合 (例えば、実装が検証ツール (Validator) である場合) を除き、メッセージを完全に拒否すべきではありません (SHOULD NOT)。したがって、無効なフィールドのデフォルト処理は、それらを無視することです。