メインコンテンツまでスキップ

附録A. RFC 2616定義からの変更点 (Changes from the RFC 2616 Definition)

[RFC2616]のセクション19.5.1と比較して、実際の実装を反映した以下の規範的変更が行われました:

  • RFC 2616によれば、処置タイプ (Disposition Type) "attachment" はタイプ "application/octet-stream" のコンテンツにのみ適用されます。この制限は削除されました。なぜなら、受信者は実際にはコンテンツタイプ (Content Type) をチェックせず、またこの制限はメディアタイプ (Media Type) を適切に宣言することを妨げるからです。

  • RFC 2616はfilenameパラメータに対して "quoted-string" のみを許可しています。これは例外的なパラメータ構文となり、また実際の使用を反映していません。

  • 処置タイプ "inline" の定義 ([RFC2183]のセクション2.1) が、その処理に関する提案とともに再追加されました。

  • 本仕様は[RFC5987]で定義された拡張パラメータエンコーディング (Extended Parameter Encoding) のサポートを必要とします (REQUIRED)。

附録B. RFC 2183との相違点 (Differences Compared to RFC 2183)

[RFC2183]のセクション2は、いくつかの追加の処置パラメータ (Disposition Parameter) を定義しています: "creation-date"、"modification-date"、"quoted-date-time"、及び "size"。大多数のユーザーエージェント (User Agent) はこれらを実装していないため、本仕様からは省略されました。

附録C. 国際化への代替アプローチ (Alternative Approaches to Internationalization)

デフォルトでは、HTTPヘッダーフィールドパラメータ (HTTP Header Field Parameter) はISO-8859-1 ([ISO-8859-1]) 文字エンコーディング (Character Encoding) の外の文字を運ぶことができません ([RFC2616]のセクション2.2を参照)。"filename" パラメータにとって、これはもちろん受け入れられない制限です。

残念ながら、ユーザーエージェント実装者は相互運用可能なアプローチを考え出すことができませんでした。IETF標準化過程 (IETF Standards Track) は正確に1つの解決策を規定していますが ([RFC2231]、[RFC5987]でHTTPのために明確化およびプロファイル化)。

完全性のために、以下のセクションでは試みられた様々なアプローチについて説明し、本仕様で使用されるRFC 5987エンコーディング (Encoding) よりも劣っている理由を説明します。

C.1. RFC 2047エンコーディング (RFC 2047 Encoding)​

RFC 2047はヘッダーフィールド (Header Field) のためのエンコーディングメカニズム (Encoding Mechanism) を定義していますが、このエンコーディングはヘッダーフィールドパラメータに使用されるべきではありません -- [RFC2047]のセクション5を参照:

'encoded-word' は 'quoted-string' 内に出現してはなりません (MUST NOT)。

...

'encoded-word' は、MIME Content-TypeまたはContent-Dispositionフィールドのパラメータ、または 'comment' または 'phrase' 内を除く任意の構造化フィールド本体で使用してはなりません (MUST NOT)。

実際には、一部のユーザーエージェントはエンコーディングを実装し、一部は実装せず (エンコードされた文字列をユーザーに公開)、一部はそれによって混乱します。

C.2. パーセントエンコーディング (Percent Encoding)​

一部のユーザーエージェントは、パーセントエンコードされた ([RFC3986]のセクション2.1) 文字シーケンス (Character Sequence) を受け入れます。デコードに使用される文字エンコーディングは、参照ページ (Referring Page) のエンコーディング、ユーザーエージェントのロケール (Locale)、その設定、及びパラメータの実際の値を含む様々な要因に依存します。

実際には、これを使用するのは困難です。なぜなら、これをサポートしないユーザーエージェントはエスケープされた文字シーケンスをユーザーに表示するからです。これを実装するユーザーエージェントにとっては、実際に期待される文字エンコーディングを予測することが困難です。

C.3. エンコーディング推測 (Encoding Sniffing)​

一部のユーザーエージェントは値 (quoted-string形式の場合、デフォルトはISO-8859-1) を検査し、UTF-8がより正しい解釈である可能性が高いと思われる場合にUTF-8に切り替えます。

上記のアプローチと同様に、これは相互運用可能ではなく、さらに実際の値を誤って解釈するリスクがあります。

附録D. Content-Dispositionヘッダーフィールド生成のアドバイス (Advice on Generating Content-Disposition Header Fields)

既存および将来のユーザーエージェント (User Agent) との相互運用を成功させるために、Content-Dispositionヘッダーフィールド (Header Field) の送信者には以下のことが推奨されます:

  • US-ASCII ([US-ASCII]) が十分に表現力がある場合は、"filename" パラメータを含める。

  • filenameパラメータの 'token' 形式は、許可されていない文字 (例: スペース) を含まない場合にのみ使用する。そのような場合は、quoted-string形式を使用すべきです。

  • 一部の既存の実装はそれをエスケープ文字 (Escape Character) と見なし、他の実装はそれを変更せずに渡すため、filenameパラメータにパーセント文字の後に2桁の16進数 (例: %A9) を含めることを避ける。

  • 一部のユーザーエージェントによってエスケープが実装されておらず、"\" は不正なパス文字 (Path Character) と見なされる可能性があるため、filenameパラメータのquoted-string形式に "\" 文字を含めることを避ける。

  • filenameパラメータに非ASCII文字を使用することを避ける。ほとんどの既存の実装はそれらをISO-8859-1としてデコードしますが、一部はUTF-8を検出するためにヒューリスティック (Heuristic) を適用するため、特定の名前で失敗する可能性があります。

  • 望ましいファイル名が "filename" 形式を使用して忠実に表現できない場合は、"filename*" パラメータを含める。レガシーユーザーエージェント (Legacy User Agent) はこれを処理せず、"filename" パラメータの内容を使用するフォールバック (Fallback) を行うことに注意してください。

  • "filename*" パラメータが送信される場合、"filename*" 形式をサポートしないユーザーエージェントのためのフォールバックとして "filename" パラメータも生成する (可能であれば)。これは、文字をUS-ASCIIシーケンスで置換することによって行うことができます (例: Unicode文字ポイント U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) を "ae" で)。これは一部のロケールでは不可能である可能性があることに注意してください。

  • "filename" パラメータがフォールバックとして含まれる場合 (上記のとおり)、一部の既存実装の解析問題により、"filename" が最初に出現すべきです。

  • "filename*" パラメータが存在する場合、UTF-8をそのエンコーディングとして使用する。なぜなら、少なくとも1つの既存実装はそのエンコーディングのみを実装しているからです。

注記: このアドバイスは執筆時点のユーザーエージェント (UA) の動作に基づいており、更新される可能性があります。本文書の発行時点では、http://purl.org/NET/http/content-disposition-tests が様々な実装における現在のサポートレベルの概要を提供しています。

に最終更新