[要約] RFC 6266は、HTTP応答における「Content-Disposition」ヘッダーフィールドの使用法を規定し、ブラウザがコンテンツを表示するか保存するかを制御する手法を定義しています。inlineやattachmentといったディスポジションタイプに加え、マルチバイト文字を含むファイル名を安全に伝えるための「filename*」パラメータの書式を規定しています。ダウンロード時のファイル名が文字化けしたり意図しない形式で保存されたりする問題を解消し、Webアプリケーションの使い勝手を向上させます。
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 6266 greenbytes
Updates: 2616 June 2011
Category: Standards Track
ISSN: 2070-1721
Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
Hypertext Transfer Protocol (HTTP) における Content-Disposition ヘッダーフィールドの使用
Abstract
概要
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.
RFC 2616は、Content-Disposition応答ヘッダーフィールドを定義していますが、これがHTTP/1.1標準の一部ではないことを指摘しています。この仕様は、HTTPで使用されるContent-Dispositionの定義と登録を引き継ぎ、国際化の側面を明確にします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。これはIETFコミュニティのコンセンサスを表しています。このドキュメントは公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）によって出版が承認されました。インターネット標準の詳細については、RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6266.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6266 で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2011 IETF Trustおよび文書の著者として特定された人物。All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの公開日に有効なBCP 78およびIETFドキュメントに関連するIETF Trustの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントには、このドキュメントに関するお客様の権利と制限が記載されているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trustの法的規定のセクション4.eに記載されているSimplified BSD Licenseのテキストを含める必要があり、Simplified BSD Licenseに記載されている通り、保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Notational Conventions ..........................................3
3. Conformance and Error Handling ..................................3
4. Header Field Definition .........................................3
4.1. Grammar ....................................................4
4.2. Disposition Type ...........................................5
4.3. Disposition Parameter: 'Filename' ..........................5
4.4. Disposition Parameter: Extensions ..........................6
4.5. Extensibility ..............................................7
5. Examples ........................................................7
6. Internationalization Considerations .............................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registry for Disposition Values and Parameters .............8
8.2. Header Field Registration ..................................8
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Appendix A. Changes from the RFC 2616 Definition ..................11
Appendix B. Differences Compared to RFC 2183 ......................11
Appendix C. Alternative Approaches to Internationalization ........11
C.1. RFC 2047 Encoding ..........................................12
C.2. Percent Encoding ...........................................12
C.3. Encoding Sniffing ..........................................12
Appendix D. Advice on Generating Content-Disposition Header
Fields ................................................13
RFC 2616 defines the Content-Disposition response header field (Section 19.5.1 of [RFC2616]) but points out that it is not part of the HTTP/1.1 Standard (Section 15.5):
RFC 2616は、Content-Disposition応答ヘッダーフィールドを定義していますが（[RFC2616]のセクション19.5.1）、これがHTTP/1.1標準の一部ではないことを指摘しています（セクション15.5）。
Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementers.
Content-DispositionはHTTP標準の一部ではありませんが、広く実装されているため、実装者のためにその使用方法とリスクを文書化しています。
This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability testing with existing user agents (UAs), it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions (MIME) variant ([RFC2183]) of the header field, and also clarifies internationalization aspects.
この仕様は、HTTPで使用されるContent-Dispositionの定義と登録を引き継ぎます。既存のユーザーエージェント（UA）との相互運用性テストに基づき、ヘッダーフィールドのMIME（Multipurpose Internet Mail Extensions）バリアント（[RFC2183]）で定義された機能のプロファイルを完全に定義し、国際化の側面も明確にします。
Note: This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).
注：このドキュメントは、メディアタイプ "multipart/form-data"（[RFC2388]）を使用する場合など、HTTPを介して送信されるペイロードボディに表示されるContent-Dispositionヘッダーフィールドには適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119]に記載されている通りに解釈されます。
This specification uses the augmented BNF (ABNF) notation defined in Section 2.1 of [RFC2616], including its rules for implied linear whitespace (LWS).
この仕様では、[RFC2616]のセクション2.1で定義されている拡張BNF（ABNF）表記を使用しており、これには暗黙の線形空白（LWS）の規則も含まれます。
This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP user agents) of the Content-Disposition header field. An implementation is considered conformant if it complies with all of the requirements associated with its role.
この仕様は、Content-Dispositionヘッダーフィールドの送信者（通常はHTTPオリジンサーバー）と受信者（通常はHTTPユーザーエージェント）の両方の適合基準を定義します。実装がその役割に関連するすべての要件に準拠している場合、適合していると見なされます。
This specification also defines certain forms of the header field value to be invalid, using both ABNF and prose requirements (Section 4), but it does not define special handling of these invalid field values.
この仕様はまた、ABNFと説明文の両方の要件（セクション4）を使用して、ヘッダーフィールド値の特定の形式を無効として定義していますが、これらの無効なフィールド値の特別な処理については定義していません。
Senders MUST NOT generate Content-Disposition header fields that are invalid.
送信者は、無効なContent-Dispositionヘッダーフィールドを生成してはなりません。
Recipients MAY take steps to recover a usable field value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behavior (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them.
受信者は、無効なヘッダーフィールドから使用可能なフィールド値を回復するための措置を講じることができますが、明示的に望ましい動作（例えば、実装がバリデータである場合など）でない限り、メッセージを即座に拒否すべきではありません。そのため、無効なフィールドのデフォルトの処理は、それらを無視することです。
The Content-Disposition response header field is used to convey additional information about how to process the response payload, and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.
Content-Disposition応答ヘッダーフィールドは、レスポンスペイロードの処理方法に関する追加情報を伝えるために使用され、レスポンスペイロードをローカルに保存する際に使用するファイル名などの追加のメタデータを添付するためにも使用できます。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "inline" | "attachment" | disp-ext-type
; case-insensitive
disp-ext-type = token
disposition-parm = filename-parm | disp-ext-parm
filename-parm = "filename" "=" value
| "filename*" "=" ext-value
disp-ext-parm = token "=" value
| ext-token "=" ext-value
ext-token = <the characters in token, followed by "*">
Defined in [RFC2616]:
[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
Defined in [RFC5987]:
[RFC5987]で定義されています。
ext-value = <ext-value, defined in [RFC5987], Section 3.2>
Content-Disposition header field values with multiple instances of the same parameter name are invalid.
同じパラメータ名が複数存在するContent-Dispositionヘッダーフィールド値は無効です。
Note that due to the rules for implied linear whitespace (Section 2.1 of [RFC2616]), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters.
[RFC2616]のセクション2.1の暗黙の線形空白の規則により、単語（トークンまたは引用符付き文字列）とセパレータ文字の間にオプションの空白が含まれる可能性があることに注意してください。
Furthermore, note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited use for filenames and is likely to be ignored by recipients.
さらに、ext-valueに使用される形式では自然言語を指定できますが（例："en"）、これはファイル名に関しては用途が限られており、受信者によって無視される可能性があります。
If the disposition type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user to save the response locally, rather than process it normally (as per its media type).
ディスポジションタイプが（大文字小文字を区別せずに）"attachment"に一致する場合、これは受信者がメディアタイプに従って通常通り処理するのではなく、レスポンスをローカルに保存するようにユーザーに促すべきであることを示します。
On the other hand, if it matches "inline" (case-insensitively), this implies default processing. Therefore, the disposition type "inline" is only useful when it is augmented with additional parameters, such as the filename (see below).
一方、"inline"に（大文字小文字を区別せずに）一致する場合、これはデフォルトの処理を意味します。したがって、ディスポジションタイプ "inline" は、ファイル名などの追加のパラメータ（以下を参照）で補完されている場合にのみ有用です。
Unknown or unhandled disposition types SHOULD be handled by recipients the same way as "attachment" (see also [RFC2183], Section 2.8).
未知のまたは未処理のディスポジションタイプは、受信者によって "attachment" と同様に処理されるべきです（[RFC2183]のセクション2.8も参照）。
The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename for storing the message payload.
パラメータ "filename" および "filename*" は、大文字小文字を区別せずに照合され、メッセージペイロードを保存するためのファイル名を構築する方法に関する情報を提供します。
Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page being displayed).
ディスポジションタイプに応じて、この情報はすぐに使用される場合（"attachment" ディスポジションタイプによって引き起こされる「名前を付けて保存...」のインタラクション時）もあれば、後で使用される場合（例えば、ユーザーが表示されている現在のページの内容を保存することを決定したとき）もあります。
The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).
パラメータ "filename" と "filename*" の違いは、"filename*" が [RFC5987] で定義されたエンコーディングを使用し、ISO-8859-1 文字セット ([ISO-8859-1]) に存在しない文字を使用できる点のみです。
Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when both "filename" and "filename*" are present in a single header field value, recipients SHOULD pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see Section 5 for an example).
この仕様より前の多くのユーザーエージェント実装は、"filename*" パラメータを理解しません。したがって、単一のヘッダーフィールド値に "filename" と "filename*" の両方が存在する場合、受信者は "filename*" を選択し、"filename" を無視すべきです。これにより、送信者は、より表現力のある "filename*" パラメータと、レガシーな受信者のためのフォールバックとして "filename" パラメータの両方を送信することで、特定のユーザーエージェントを特別扱いすることを回避できます（例についてはセクション5を参照）。
It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the desired information. In particular:
受信者が、指定されたファイル名をアドバイザリ（助言）としてのみ扱い、目的の情報を抽出する際に細心の注意を払うことが不可欠です。特に以下の点に注意してください。
o Recipients MUST NOT be able to write into any location other than one to which they are specifically entitled. To illustrate the problem, consider the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this is to never trust folder name information in the filename parameter, for instance by stripping all but the last path segment and only considering the actual filename (where 'path segments' are the components of the field value delimited by the path separator characters "\" and "/").
o 受信者は、特別に権利を与えられている場所以外に書き込みができてはなりません。この問題を説明するために、よく知られたシステムの場所（"/etc/passwd" など）を上書きできることの結果を考慮してください。これを達成するための戦略の1つは、filenameパラメータのフォルダ名情報を決して信頼しないことです。例えば、最後のパスセグメントを除くすべてを取り除き、実際のファイル名のみを考慮します（ここで「パスセグメント」は、パス区切り文字「\」および「/」で区切られたフィールド値のコンポーネントです）。
o Many platforms do not use Internet Media Types ([RFC2046]) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that make use of file extensions to determine the media type MUST ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
o 多くのプラットフォームは、ファイルシステムにタイプ情報を保持するためにインターネットメディアタイプ（[RFC2046]）を使用せず、代わりにファイル名の拡張子に依存しています。サーバーから提供されたファイル拡張子を信頼すると、保存されたファイルが後で開かれたときに特権の昇格を招く可能性があります（".exe" を考慮してください）。したがって、ファイル拡張子を使用してメディアタイプを決定する受信者は、安全なファイル拡張子が使用されていることを確認し、受信したペイロードのメディアタイプに最適に一致させる必要があります。
o Recipients SHOULD strip or replace character sequences that are known to cause confusion both in user interfaces and in filenames, such as control characters and leading and trailing whitespace.
o 受信者は、制御文字や先頭および末尾の空白など、ユーザーインターフェースとファイル名の両方で混乱を引き起こすことが知られている文字シーケンスを削除または置換すべきです。
o Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, such as "." and "..", "~", "|", and also device names. Recipients SHOULD ignore or substitute names like these.
o 受信者が注意する必要がある他の側面として、"." や ".."、"~"、"|" など、ファイルシステムやシェルコマンドで特別な意味を持つ名前、およびデバイス名があります。受信者は、このような名前を無視するか、別の名前に置き換えるべきです。
Note: Many user agents do not properly handle the escape character "\" when using the quoted-string form. Furthermore, some user agents erroneously try to perform unescaping of "percent" escapes (see Appendix C.2), and thus might misinterpret filenames containing the percent character followed by two hex digits.
注：多くのユーザーエージェントは、引用符付き文字列（quoted-string）形式を使用する際にエスケープ文字 "\" を適切に処理しません。さらに、一部のユーザーエージェントは、誤って「パーセント」エスケープのアンエスケープを実行しようとするため（付録C.2を参照）、パーセント文字の後に2桁の16進数が続くファイル名を誤認する可能性があります。
To enable future extensions, recipients SHOULD ignore unrecognized parameters (see also [RFC2183], Section 2.8).
将来の拡張を可能にするため、受信者は認識できないパラメータを無視すべきです（[RFC2183]のセクション2.8も参照）。
Note that Section 9 of [RFC2183] defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP.
[RFC2183]のセクション9では、ディスポジションタイプとディスポジションパラメータの両方のIANAレジストリを定義していることに注意してください。このレジストリは、MIMEやHTTPなど、Content-Dispositionを使用する異なるプロトコル間で共有されます。したがって、登録されたすべての値がHTTPの文脈で意味をなすとは限りません。
Direct the UA to show "save as" dialog, with a filename of "example.html":
UAに「名前を付けて保存」ダイアログを表示するように指示し、ファイル名を "example.html" とします。
Content-Disposition: Attachment; filename=example.html
Direct the UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" for a subsequent save operation:
Content-Dispositionヘッダーフィールドが存在しないかのように動作するようUAに指示しますが、その後の保存操作のためにファイル名 "an example.html" を記憶しておきます。
Content-Disposition: INLINE; FILENAME= "an example.html"
Note: This uses the quoted-string form so that the space character can be included.
注：これは、スペース文字を含めることができるように引用符付き文字列形式を使用しています。
Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):
Unicode文字 U+20AC (EURO SIGN) を含むファイル名で、UAに「名前を付けて保存」ダイアログを表示するように指示します。
Content-Disposition: attachment;
filename*= UTF-8''%e2%82%ac%20rates
Here, the encoding defined in [RFC5987] is also used to encode the non-ISO-8859-1 character.
ここでは、[RFC5987] で定義されたエンコーディングが、非ISO-8859-1文字のエンコードにも使用されています。
This example is the same as the one above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:
この例は上記と同じですが、RFC 5987を実装していないユーザーエージェントとの互換性のために "filename" パラメータを追加しています。
Content-Disposition: attachment;
filename="EURO rates";
filename*=utf-8''%e2%82%ac%20rates
Note: Those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after "filename".
注：RFC 5987エンコーディングをサポートしていないユーザーエージェントは、"filename" の後に "filename*" が出現した場合、それを無視します。
The "filename*" parameter (Section 4.3), using the encoding defined in [RFC5987], allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language in use.
[RFC5987] で定義されたエンコーディングを使用した "filename*" パラメータ（セクション4.3）を使用すると、サーバーはISO-8859-1文字セット以外の文字を送信でき、またオプションで使用言語を指定することもできます。
Future parameters might also require internationalization, in which case the same encoding can be used.
将来のパラメータも国際化を必要とする可能性がありますが、その場合は同じエンコーディングを使用できます。
Using server-supplied information for constructing local filenames introduces many risks. These are summarized in Section 4.3.
ローカルファイル名を構築するためにサーバーから提供された情報を使用することには多くのリスクが伴います。これらはセクション4.3にまとめられています。
Furthermore, implementers ought to be aware of the security considerations applying to HTTP (see Section 15 of [RFC2616]), and also the parameter encoding defined in [RFC5987] (see Section 5).
さらに、実装者はHTTPに適用されるセキュリティ上の考慮事項（[RFC2616]のセクション15を参照）および [RFC5987] で定義されているパラメータエンコーディング（セクション5を参照）を認識しておく必要があります。
This specification does not introduce any changes to the registration procedures for disposition values and parameters that are defined in Section 9 of [RFC2183].
この仕様は、[RFC2183]のセクション9で定義されているディスポジション値とパラメータの登録手順に変更を導入するものではありません。
This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry (see [RFC3864]).
このドキュメントは、永続的なHTTPヘッダーフィールドレジストリにおける Content-Disposition HTTPヘッダーフィールドの定義を更新します（[RFC3864]を参照）。
Header field name: Content-Disposition
ヘッダーフィールド名：Content-Disposition
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更責任者：IETF
Specification document: this specification (Section 4)
仕様書：この仕様書（セクション4）
Related information: none
関連情報：なし
Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik Nordstrom, and Mark Nottingham for their valuable feedback.
貴重なフィードバックをいただいた Adam Barth、Rolf Eike Beer、Stewart Bryant、Bjoern Hoehrmann、Alfred Hoenes、Roar Lauritzsen、Alexey Melnikov、Henrik Nordstrom、および Mark Nottingham の各氏に感謝します。
[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.
[ISO-8859-1] 国際標準化機構、「情報技術 -- 8ビットシングルバイト符号化グラフィック文字セット -- 第1部：ラテンアルファベット第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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月。
[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.
[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, 1999年6月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, 2010年8月。
10.2. Informative References
10.2. 参考引用
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, 1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1996年11月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, 1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, 1997年11月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/form-data", RFC 2388, 1998年8月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, 2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2005年1月。
[US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986年。
Compared to Section 19.5.1 of [RFC2616], the following normative changes reflecting actual implementations have been made:
[RFC2616] のセクション19.5.1と比較して、実際の実装を反映した以下の規範的な変更が行われました。
o According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly declaring the media type.
o RFC 2616によると、ディスポジションタイプ "attachment" はメディアタイプ "application/octet-stream" のコンテンツにのみ適用されます。実際には受信者はコンテンツタイプをチェックせず、またメディアタイプを適切に宣言することを妨げるため、この制限は削除されました。
o RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't reflect actual use.
o RFC 2616では、filenameパラメータに対して "quoted-string" のみが許可されていました。これは例外的なパラメータ構文であり、また実際の使用状況も反映していません。
o The definition for the disposition type "inline" ([RFC2183], Section 2.1) has been re-added with a suggestion for its processing.
o ディスポジションタイプ "inline" ([RFC2183]のセクション2.1) の定義が、その処理に関する提案とともに再追加されました。
o This specification requires support for the extended parameter encoding defined in [RFC5987].
o この仕様は、[RFC5987] で定義された拡張パラメータエンコーディングのサポートを要求しています。
Section 2 of [RFC2183] defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The majority of user agents do not implement these; thus, they have been omitted from this specification.
[RFC2183] のセクション2では、"creation-date"、"modification-date"、"quoted-date-time"、"size" といういくつかの追加のディスポジションパラメータが定義されています。大多数のユーザーエージェントはこれらを実装していないため、この仕様からは除外されました。
By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see [RFC2616], Section 2.2). For the "filename" parameter, this of course is an unacceptable restriction.
デフォルトでは、HTTPヘッダーフィールドのパラメータは ISO-8859-1 ([ISO-8859-1]) 文字エンコーディング以外の文字を運ぶことができません（[RFC2616]のセクション2.2を参照）。"filename" パラメータにとって、これはもちろん容認できない制限です。
Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards Track specifies exactly one solution ([RFC2231], clarified and profiled for HTTP in [RFC5987]).
残念ながら、IETF Standards Trackがまさに1つの解決策（[RFC2231]、[RFC5987] でHTTP向けに明確化およびプロファイル化されたもの）を指定しているにもかかわらず、ユーザーエージェントの実装者は相互運用可能なアプローチを考案できていません。
For completeness, the sections below describe the various approaches that have been tried, and explain how they are inferior to the RFC 5987 encoding used in this specification.
完全を期すため、以下のセクションでは試行された様々なアプローチについて説明し、それらがこの仕様で使用されている RFC 5987 エンコーディングよりどのように劣っているかを説明します。
RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters -- see Section 5 of [RFC2047]:
RFC 2047 はヘッダーフィールドのエンコードメカニズムを定義していますが、このエンコードはヘッダーフィールドのパラメータに使用されるべきではありません。[RFC2047] のセクション5を参照してください。
An 'encoded-word' MUST NOT appear within a 'quoted-string'.
'encoded-word' は 'quoted-string' 内に出現してはなりません。
...
...
An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
'encoded-word' は、MIMEの Content-Type や Content-Disposition フィールドのパラメータ、あるいは 'comment' や 'phrase' 内を除く構造化フィールド本体で使用してはなりません。
In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get confused by it.
実際には、一部のユーザーエージェントはこのエンコードを実装しており、一部は実装しておらず（エンコードされた文字列をユーザーにそのまま表示する）、また一部はそれによって混乱をきたします。
Some user agents accept percent-encoded ([RFC3986], Section 2.1) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
一部のユーザーエージェントは、パーセントエンコードされた（[RFC3986]のセクション2.1）文字シーケンスを受け入れます。デコードに使用される文字エンコーディングは、参照元のページのエンコーディング、ユーザーエージェントのロケール、設定、およびパラメータの実際の値など、様々な要因に依存します。
In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually expect.
実際には、これをサポートしていないユーザーエージェントはエスケープされた文字シーケンスをそのままユーザーに表示するため、これを使用するのは困難です。これを実装しているユーザーエージェントであっても、実際にどの文字エンコーディングを期待しているかを予測するのは困難です。
Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems to be more likely to be the correct interpretation.
一部のユーザーエージェントは値を検査し（引用符付き文字列形式の場合はデフォルトで ISO-8859-1）、UTF-8の方が正しい解釈である可能性が高いと思われる場合に UTF-8 に切り替えます。
As with the approaches above, this is not interoperable and, furthermore, risks misinterpreting the actual value.
上記のアプローチと同様に、これは相互運用性がなく、さらに実際の値を誤認するリスクがあります。
To successfully interoperate with existing and future user agents, senders of the Content-Disposition header field are advised to:
既存および将来のユーザーエージェントと正常に相互運用するために、Content-Dispositionヘッダーフィールドの送信者は以下のようにすることをお勧めします。
o Include a "filename" parameter when US-ASCII ([US-ASCII]) is sufficiently expressive.
o US-ASCII ([US-ASCII]) で十分に表現できる場合は、"filename" パラメータを含める。
o Use the 'token' form of the filename parameter only when it does not contain disallowed characters (e.g., spaces); in such cases, the quoted-string form should be used.
o 許可されていない文字（例：スペース）が含まれていない場合にのみ、filenameパラメータの 'token' 形式を使用する。そのような場合は、引用符付き文字列形式を使用すべきである。
o Avoid including the percent character followed by two hexadecimal characters (e.g., %A9) in the filename parameter, since some existing implementations consider it to be an escape character, while others will pass it through unchanged.
o filenameパラメータに、パーセント文字の後に2つの16進文字が続くもの（例：%A9）を含めることは避ける。一部の実装ではそれをエスケープ文字と見なし、他の実装ではそのまま通してしまうためである。
o Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "\" can be considered an illegal path character.
o filenameパラメータの引用符付き文字列形式に "\" 文字を含めることは避ける。エスケープが一部のユーザーエージェントで実装されておらず、"\" が不正なパス文字と見なされる可能性があるためである。
o Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1, some will apply heuristics to detect UTF-8, and thus might fail on certain names.
o filenameパラメータで非ASCII文字を使用することは避ける。ほとんどの既存の実装はそれらを ISO-8859-1 としてデコードするが、一部の実装は UTF-8 を検出するためにヒューリスティックを適用するため、特定の名前で失敗する可能性がある。
o Include a "filename*" parameter where the desired filename cannot be expressed faithfully using the "filename" form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.
o 目的のファイル名を "filename" 形式で忠実に表現できない場合は、"filename*" パラメータを含める。レガシーなユーザーエージェントはこれを処理せず、"filename" パラメータの内容を使用するようにフォールバックすることに注意する。
o When a "filename*" parameter is sent, to also generate a "filename" parameter as a fallback for user agents that do not support the "filename*" form, if possible. This can be done by substituting characters with US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by "ae"). Note that this may not be possible in some locales.
o "filename*" パラメータを送信する際は、可能であれば "filename*" 形式をサポートしていないユーザーエージェントのためのフォールバックとして "filename" パラメータも生成する。これは、文字を US-ASCII シーケンスに置き換えることで行える（例：Unicode文字ポイント U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) を "ae" に置換）。ただし、一部のロケールではこれが不可能な場合があることに注意する。
o When a "filename" parameter is included as a fallback (as per above), "filename" should occur first, due to parsing problems in some existing implementations.
o （上記のように）フォールバックとして "filename" パラメータを含める場合、一部の既存の実装におけるパースの問題を避けるため、"filename" を先に出現させるべきである。
o Use UTF-8 as the encoding of the "filename*" parameter, when present, because at least one existing implementation only implements that encoding.
o "filename*" パラメータが存在する場合、少なくとも1つの既存の実装がそのエンコーディングのみを実装しているため、エンコーディングとして UTF-8 を使用する。
Note that this advice is based upon UA behavior at the time of writing, and might be superseded. At the time of publication of this document, <http://purl.org/NET/http/content-disposition-tests> provides an overview of current levels of support in various implementations.
このアドバイスは執筆時点のUAの動作に基づいており、将来変更される可能性があることに注意してください。このドキュメントの公開時点では、<http://purl.org/NET/http/content-disposition-tests> に様々な実装における現在のサポートレベルの概要が記載されています。
Author's Address
著者の住所
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/