インターネット技術標準化委員会 (IETF)

J. Reschke

Request for Comments: 7694

greenbytes

カテゴリ: 標準化トラック

2015年11月

ISSN: 2070-1721

ハイパーテキスト転送プロトコル (HTTP) におけるクライアント発起のコンテンツエンコーディング

概要

HTTP では、コンテンツ符号化（content coding）により圧縮や整合性チェックなどのペイロードのエンコードが可能です。特に "gzip" コンテンツ符号化は、レスポンスメッセージ内で送信されるペイロードデータに広く使われています。

コンテンツ符号化はリクエストメッセージでも使用できますが、発見可能性（discoverability）はレスポンスメッセージと同等ではありません。本ドキュメントは、リクエストでサポートされるコンテンツ符号化を示すために、応答で使用される HTTP の "Accept-Encoding" ヘッダーフィールドを拡張します。

このメモのステータス

これはインターネット標準化トラック文書です。

本書はインターネット技術標準化委員会（IETF）の成果物です。本書は IETF コミュニティの合意を表しており、公開のために一般レビューを経てインターネット技術運営指導グループ（IESG）によって承認されています。インターネット標準に関する詳細は RFC 5741 のセクション2 を参照してください。

本書の現在のステータス、正誤表、フィードバックの提供方法については http://www.rfc-editor.org/info/rfc7694 を参照してください。

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.

1. はじめに
2. 記法上の規約
3. レスポンスでの 'Accept-Encoding' ヘッダーフィールドの使用
4. 例
5. 配備に関する考慮事項
6. セキュリティに関する考慮事項
7. IANA に関する考慮事項
- 7.1. ヘッダーフィールドレジストリ
- 7.2. ステータスコードレジストリ
8. 参考文献
- 8.1. 規範的参考文献
- 8.2. 参考情報
謝辞
著者の連絡先

1. はじめに

HTTP において、コンテンツ符号化は圧縮や整合性チェックのようなペイロードのエンコーディングを可能にします（[RFC7231]、 Section 3.1.2）。特に、"gzip" コンテンツ符号化（[RFC7230]、 Section 4.2）は、レスポンスメッセージで送信されるペイロードデータに広く利用されています。

コンテンツ符号化はリクエストメッセージでも使用可能ですが、その発見可能性はレスポンスメッセージと同等ではありません。本書は、HTTP の "Accept-Encoding" ヘッダーフィールド（[RFC7231]、 Section 5.3.4）を、リクエストでサポートされるコンテンツ符号化を示すためにレスポンスでも使用できるように拡張します。さらに、ステータスコード 415 (Unsupported Media Type) の定義（[RFC7231]、 Section 6.5.13）を更新し、適切な場合に "Accept-Encoding" ヘッダーフィールドを含めることを推奨します。

2. 記法上の規約

本書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、 "RECOMMENDED"、"MAY"、および "OPTIONAL" は [RFC2119] に従って解釈されます。

本書は基礎となる HTTP 仕様で定義された用語を再利用します。具体的には、Section 2 の [RFC7230]、および Section 3.1.2 の [RFC7231] にある用語を再利用します。

3. レスポンスでの 'Accept-Encoding' ヘッダーフィールドの使用

Section 5.3.4 の [RFC7231] は "Accept-Encoding" をリクエストヘッダーフィールドとして定義しています。

本仕様はその定義を拡張し、"Accept-Encoding" をレスポンスヘッダーフィールドとしても許可します。レスポンス中に存在する場合、それは当該レスポンスに関連するリクエストでリソースが受け入れていたコンテンツ符号化を示します。フィールド値が "identity" のみを含む場合は、コンテンツ符号化がサポートされていなかったことを意味します。

なお、この情報は関連するリクエストに固有のものであり、同一サーバー上の他のリソースに対するサポートされるエンコーディング集合は異なる可能性があり、時間とともに変化したり、リクエストの他の側面（例: リクエストメソッド）に依存したりすることがあります。

Section 6.5.13 の [RFC7231] は、メディア型とコンテンツ符号化の両方に関連する問題に対してステータスコード 415 (Unsupported Media Type) を適用することを定義しています。

サーバーがサポートされないコンテンツ符号化のためにリクエストを失敗させた場合、415 ステータスで応答し、そのレスポンスに "Accept-Encoding" ヘッダーフィールドを含めるべきです。これによりクライアントはコンテンツ符号化に関連する問題とメディア型に関連する問題を区別できます。メディア型に関連しない理由で 415 を返す場合、混乱を避けるためにサーバーは "Accept-Encoding" ヘッダーフィールドを含めてはなりません MUST NOT。

"Accept-Encoding" をレスポンスで使用する最も一般的な用途は、クライアントが楽観的にコンテンツ符号化を用いた場合に対する 415 応答であることが予想されます。ただし、このヘッダーフィールドは将来のやりとりを最適化するために、コンテンツ符号化がサポートされていることをクライアントに通知する目的でも使用できます。例えば、リクエストペイロードが圧縮の使用に値するほど大きかったがクライアントが圧縮を行わなかった場合に、リソースが 2xx レスポンスでこれを含めることがあります。

4. 例

クライアントが "compress" コンテンツ符号化を使用して POST リクエストを送信する例（[RFC7231]、 Section 3.1.2.1）:

POST /edit/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Content-Encoding: compress

...compressed payload...

サーバーが、そのリソースが "gzip" コンテンツ符号化しか許可していないためリクエストを拒否する例:

HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: gzip
Content-Length: 68
Content-Type: text/plain

このリソースはリクエストにおける "gzip" コンテンツ符号化のみをサポートします。

この時点で、クライアントはサポートされている "gzip" コンテンツ符号化でリクエストを再試行できます。

あるいは、リクエスト内でコンテンツ符号化を一切サポートしないサーバーは、次のように応答することもできます:

HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: identity
Content-Length: 61
Content-Type: text/plain

このリソースはリクエスト内のコンテンツ符号化をサポートしていません。

5. 配備に関する考慮事項

リクエストでのコンテンツ符号化をサポートしないサーバーは、コンテンツ符号化を使用したリクエストを既に失敗させるよう要求されています。Section 6.5.13 の [RFC7231] はこの目的のためにステータスコード 415 を定義しているため、必要な変更はそのレスポンスに値 "identity" の "Accept-Encoding" ヘッダーフィールドを含めることだけです。

いくつかのコンテンツ符号化をサポートするサーバーは、サポートされていないコンテンツ符号化を用いたリクエストも失敗させる必要があります。本仕様に準拠するために、サーバーは問題を示すためにステータスコード 415 を使用し、サポートされているコンテンツ符号化を列挙した "Accept-Encoding" ヘッダーフィールドを含める必要があります。サポートされるコンテンツ符号化の集合は通常静的かつ小規模であるため、ヘッダーフィールドを追加することは簡単であるべきです。

6. セキュリティに関する考慮事項

本仕様はサポートされるコンテンツ符号化の発見性と、サポートされないコンテンツ符号化によるリクエスト失敗の診断を追加するだけです。そのため、HTTP/1.1（Section 9 の [RFC7231]）や HTTP/2（Section 10 の [RFC7540]）に既に存在するセキュリティ上の考慮事項を超える新たな懸念を導入するものではありません。

しかしながら、発見性と診断の向上により、リクエストでのコンテンツ符号化の利用が容易になり、その結果 gzip のような圧縮符号化の使用が増加する可能性があります（Section 4.2 の [RFC7230]）。セキュアチャネル上で使用される場合、これは BREACH のようなサイドチャネル攻撃を可能にする場合があります（RFC7540 Section 10.6 と [BREACH]を参照）。公開時点では、リクエスト内の圧縮に対して BREACH 類似の攻撃がどのように適用されるかは明確ではありません。

7. IANA に関する考慮事項

7.1. ヘッダーフィールドレジストリ

HTTP ヘッダーフィールドは、BCP90（"Message Headers" レジストリ）で定義されている <http://www.iana.org/assignments/message-headers> に登録されます（[BCP90]参照）。

本書は "Accept-Encoding" ヘッダーフィールドの定義を更新します。恒久的メッセージヘッダーフィールド名レジストリは以下のように更新されました:

ヘッダーフィールド名	プロトコル	ステータス	参照
Accept-Encoding	http	standard	Section 5.3.4 of [RFC7231] and Section 3 of this document

7.2. ステータスコードレジストリ

HTTP ステータスコードは <http://www.iana.org/assignments/http-status-codes> にある "HTTP Status Codes" レジストリに登録されます。

本書はステータスコード 415 (Unsupported Media Type) の定義を更新します。"HTTP Status Codes" レジストリは以下のように更新されました:

値	説明	参照
415	Unsupported Media Type	Section 6.5.13 of [RFC7231] and Section 3 of this document

8. 参考文献

8.1. 規範的参考文献

[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

8.2. 参考情報

[BCP90]: Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.
[BREACH]: Gluck, Y., Harris, N., and A. Prado, “BREACH: Reviving the CRIME Attack”, July 2013, <http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[RFC7540]: Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.

謝辞

Hypertext Transfer Protocol ワーキンググループの参加者、すなわち Amos Jeffries、Ben Campbell、Mark Nottingham、Pete Resnick、Stephen Farrell、Ted Hardie に感謝します。

著者の連絡先

Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/