RFC 7694 - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7694
タイトル : RFC 7694 - ハイパーテキスト転送プロトコル（HTTP）クライアントが開始するコンテンツエンコーディング
翻訳編集 : 自動生成

[要約] RFC 7694は、HTTPクライアントがコンテンツエンコーディングを開始するための仕様です。目的は、クライアントがサーバーに対してエンコーディングの要求を行い、効率的なデータ転送を実現することです。

Internet Engineering Task Force (IETF)                        J. Reschke
Request for Comments: 7694                                    greenbytes
Category: Standards Track                                  November 2015
ISSN: 2070-1721

Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding

ハイパーテキスト転送プロトコル（HTTP）クライアントが開始するコンテンツエンコーディング

Abstract

概要

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.

HTTPでは、コンテンツコーディングにより、圧縮や整合性チェックなどのペイロードエンコーディングが可能になります。特に、「gzip」コンテンツコーディングは、応答メッセージで送信されるペイロードデータに広く使用されています。

コンテンツコーディングはリクエストメッセージでも使用できます。ただし、検出可能性は応答メッセージと同等ではありません。このドキュメントは、リクエストでサポートされるコンテンツコーディングを示すために、レスポンスで使用するためにHTTPの「Accept-Encoding」ヘッダーフィールドを拡張します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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/rfc7694.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   2
   3.  Using the 'Accept-Encoding' Header Field in Responses . . . .   3
   4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Header Field Registry . . . . . . . . . . . . . . . . . .   5
     7.2.  Status Code Registry  . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

In HTTP, content codings allow for payload encodings such as for compression or integrity checks ([RFC7231], Section 3.1.2). In particular, the "gzip" content coding ([RFC7230], Section 4.2) is widely used for payload data sent in response messages.

HTTPでは、コンテンツコーディングにより、圧縮や整合性チェックなどのペイロードエンコーディングが可能になります（[RFC7231]、セクション3.1.2）。特に、「gzip」コンテンツコーディング（[RFC7230]、セクション4.2）は、応答メッセージで送信されるペイロードデータに広く使用されています。

Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field ([RFC7231], Section 5.3.4) for use in responses, to indicate the content codings that are supported in requests. It furthermore updates the definition of status code 415 (Unsupported Media Type) ([RFC7231], Section 6.5.13), recommending that the "Accept-Encoding" header field be included when appropriate.

コンテンツコーディングはリクエストメッセージでも使用できます。ただし、検出可能性は応答メッセージと同等ではありません。このドキュメントでは、HTTP "Accept-Encoding"ヘッダーフィールド（[RFC7231]、セクション5.3.4）を拡張して応答で使用し、リクエストでサポートされているコンテンツコーディングを示します。さらに、ステータスコード415（サポートされていないメディアタイプ）（[RFC7231]、セクション6.5.13）の定義を更新し、適切な場合は「Accept-Encoding」ヘッダーフィールドを含めることを推奨しています。

2. Notational Conventions

2. 表記規則

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 document reuses terminology defined in the base HTTP specifications, namely Section 2 of [RFC7230] and Section 3.1.2 of [RFC7231].

このドキュメントでは、ベースHTTP仕様で定義されている用語、つまり[RFC7230]のセクション2と[RFC7231]のセクション3.1.2を再利用しています。

3. Using the 'Accept-Encoding' Header Field in Responses

3. 応答での「Accept-Encoding」ヘッダーフィールドの使用

Section 5.3.4 of [RFC7231] defines "Accept-Encoding" as a request header field only.

[RFC7231]のセクション5.3.4では、「Accept-Encoding」をリクエストヘッダーフィールドとしてのみ定義しています。

This specification expands that definition to allow "Accept-Encoding" as a response header field as well. When present in a response, it indicates what content codings the resource was willing to accept in the associated request. A field value that only contains "identity" implies that no content codings were supported.

この仕様では、その定義を拡張して、応答ヘッダーフィールドとして「Accept-Encoding」も許可しています。応答に含まれている場合は、関連する要求でリソースが受け入れる用意があったコンテンツコーディングを示します。「identity」のみを含むフィールド値は、コンテンツコーディングがサポートされなかったことを意味します。

Note that this information is specific to the associated request; the set of supported encodings might be different for other resources on the same server and could change over time or depend on other aspects of the request (such as the request method).

この情報は関連するリクエストに固有のものであることに注意してください。サポートされるエンコーディングのセットは、同じサーバー上の他のリソースでは異なる場合があり、時間の経過とともに変化したり、要求の他の側面（要求メソッドなど）に依存したりする場合があります。

Section 6.5.13 of [RFC7231] defines status code 415 (Unsupported Media Type) to apply to problems related to both media types and content codings.

[RFC7231]のセクション6.5.13は、ステータスコード415（サポートされていないメディアタイプ）を定義して、メディアタイプとコンテンツコーディングの両方に関連する問題に適用します。

Servers that fail a request due to an unsupported content coding ought to respond with a 415 status and ought to include an "Accept-Encoding" header field in that response, allowing clients to distinguish between issues related to content codings and media types. In order to avoid confusion with issues related to media types, servers that fail a request with a 415 status for reasons unrelated to content codings MUST NOT include the "Accept-Encoding" header field.

サポートされていないコンテンツコーディングが原因でリクエストが失敗したサーバーは、415ステータスで応答し、その応答に「Accept-Encoding」ヘッダーフィールドを含めて、クライアントがコンテンツコーディングとメディアタイプに関連する問題を区別できるようにする必要があります。メディアタイプに関連する問題との混同を避けるために、コンテンツコーディングに関係のない理由で415ステータスのリクエストに失敗したサーバーは、「Accept-Encoding」ヘッダーフィールドを含めてはなりません。

It is expected that the most common use of "Accept-Encoding" in responses will have the 415 (Unsupported Media Type) status code, in response to optimistic use of a content coding by clients. However, the header field can also be used to indicate to clients that content codings are supported, to optimize future interactions. For example, a resource might include it in a 2xx response when the request payload was big enough to justify use of a compression coding but the client failed do so.

応答での「Accept-Encoding」の最も一般的な使用は、クライアントによるコンテンツコーディングの楽観的な使用に応じて、415（サポートされていないメディアタイプ）ステータスコードになると予想されます。ただし、ヘッダーフィールドを使用して、コンテンツコーディングがサポートされていることをクライアントに示し、将来の対話を最適化することもできます。たとえば、リクエストのペイロードが圧縮コーディングの使用を正当化するのに十分な大きさであったが、クライアントが失敗した場合、リソースは2xx応答にリソースを含めることができます。

4. Example

4. 例

A client submits a POST request using the "compress" content coding ([RFC7231], Section 3.1.2.1):

クライアントは、「圧縮」コンテンツコーディング（[RFC7231]、セクション3.1.2.1）を使用してPOSTリクエストを送信します。

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

...compressed payload...

...圧縮ペイロード...

The server rejects the request because it only allows the "gzip" content coding:

「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

This resource only supports the "gzip" content coding in requests.

このリソースは、リクエストの「gzip」コンテンツコーディングのみをサポートします。

At this point, the client can retry the request with the supported "gzip" content coding.

この時点で、クライアントはサポートされている「gzip」コンテンツコーディングを使用してリクエストを再試行できます。

Alternatively, a server that does not support any content codings in requests could answer with:

または、リクエストのコンテンツコーディングをサポートしていないサーバーは、次のように応答できます。

     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

This resource does not support content codings in requests.

このリソースは、リクエストのコンテンツコーディングをサポートしていません。

5. Deployment Considerations

5. 導入に関する考慮事項

Servers that do not support content codings in requests already are required to fail a request that uses a content coding. Section 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media Type) for this purpose, so the only change needed is to include the "Accept-Encoding" header field with the value "identity" in that response.

リクエストでコンテンツコーディングをサポートしていないサーバーは、コンテンツコーディングを使用するリクエストを失敗させる必要があります。 [RFC7231]のセクション6.5.13は、この目的でステータスコード415（サポートされていないメディアタイプ）を定義しているため、必要な変更は、その応答に「identity」という値を持つ「Accept-Encoding」ヘッダーフィールドを含めることだけです。

Servers that do support some content codings are required to fail requests with unsupported content codings as well. To be compliant with this specification, servers will need to use the status code 415 (Unsupported Media Type) to signal the problem and will have to include an "Accept-Encoding" header field that enumerates the content codings that are supported. As the set of supported content codings is usually static and small, adding the header field ought to be trivial.

一部のコンテンツコーディングをサポートしているサーバーは、サポートされていないコンテンツコーディングでのリクエストも失敗する必要があります。この仕様に準拠するには、サーバーはステータスコード415（サポートされていないメディアタイプ）を使用して問題を通知する必要があり、サポートされるコンテンツコーディングを列挙する「Accept-Encoding」ヘッダーフィールドを含める必要があります。サポートされるコンテンツコーディングのセットは通常静的で小さいので、ヘッダーフィールドを追加することは簡単です。

6. Security Considerations

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

This specification only adds discovery of supported content codings and diagnostics for requests failing due to unsupported content codings. As such, it doesn't introduce any new security considerations over those already present in HTTP/1.1 (Section 9 of [RFC7231]) and HTTP/2 (Section 10 of [RFC7540]).

この仕様は、サポートされているコンテンツコーディングの検出と、サポートされていないコンテンツコーディングのために失敗したリクエストの診断のみを追加します。そのため、HTTP / 1.1（[RFC7231]のセクション9）とHTTP / 2（[RFC7540]のセクション10）にすでに存在するセキュリティ上の考慮事項は新たに導入されていません。

However, the point of better discoverability and diagnostics is to make it easier to use content codings in requests. This might lead to increased usage of compression codings such as gzip (Section 4.2 of [RFC7230]), which, when used over a secure channel, can enable side-channel attacks such as BREACH (see Section 10.6 of [RFC7540] and [BREACH]). At the time of publication, it was unclear how BREACH-like attacks can be applied to compression in HTTP requests.

ただし、発見と診断を改善するポイントは、リクエストでコンテンツコーディングを簡単に使用できるようにすることです。これにより、gzip（[RFC7230]のセクション4.2）などの圧縮コーディングの使用が増える可能性があります。これは、安全なチャネルで使用すると、BREACH（[RFC7540]のセクション10.6と[BREACH]のようなサイドチャネル攻撃を有効にすることができます。 ]）。公開時点では、BREACHのような攻撃をHTTPリクエストの圧縮にどのように適用できるかは不明でした。

7. IANA Considerations

7. IANAに関する考慮事項

7.1. Header Field Registry

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

HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/ message-headers>, as defined by [BCP90].

HTTPヘッダーフィールドは、[BCP90]で定義されているように、<http://www.iana.org/assignments/message-headers>にある「メッセージヘッダー」レジストリ内に登録されています。

This document updates the definition of the "Accept-Encoding" header field. The "Permanent Message Header Field Names" registry has been updated as follows:

このドキュメントは、「Accept-Encoding」ヘッダーフィールドの定義を更新します。 "Permanent Message Header Field Names"レジストリが次のように更新されました。

   +-----------------+----------+----------+---------------------------+
   | Header Field    | Protocol | Status   | Reference                 |
   | Name            |          |          |                           |
   +-----------------+----------+----------+---------------------------+
   | Accept-Encoding | http     | standard | Section 5.3.4 of          |
   |                 |          |          | [RFC7231] and Section 3   |
   |                 |          |          | of this document          |
   +-----------------+----------+----------+---------------------------+

7.2. Status Code Registry

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

HTTP status codes are registered within the "HTTP Status Codes" registry located at <http://www.iana.org/assignments/ http-status-codes>.

HTTPステータスコードは、<http://www.iana.org/assignments/ http-status-codes>にある「HTTPステータスコード」レジストリ内に登録されています。

This document updates the definition of the status code 415 (Unsupported Media Type). The "HTTP Status Codes" registry has been updated as follows:

このドキュメントは、ステータスコード415（サポートされていないメディアタイプ）の定義を更新します。「HTTPステータスコード」レジストリが次のように更新されました。

   +-------+-----------------+-----------------------------------------+
   | Value | Description     | Reference                               |
   +-------+-----------------+-----------------------------------------+
   | 415   | Unsupported     | Section 6.5.13 of [RFC7231] and Section |
   |       | Media Type      | 3 of this document                      |
   +-------+-----------------+-----------------------------------------+

8. References

8. 参考文献

8.1. Normative References

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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<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>.

[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。

8.2. Informative References

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>.

[BCP90] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月、<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>.

[違反] Gluck、Y.、Harris、N.、A。Prado、「BREACH：Reviving the CRIME Attack」、2013年7月、<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>.

[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<http：// www.rfc-editor.org/info/rfc7540>。

Acknowledgements

謝辞

Thanks go to the Hypertext Transfer Protocol Working Group participants, namely Amos Jeffries, Ben Campbell, Mark Nottingham, Pete Resnick, Stephen Farrell, and Ted Hardie.

ハイパーテキスト転送プロトコルワーキンググループの参加者、つまりAmos Jeffries、Ben Campbell、Mark Nottingham、Pete Resnick、Stephen Farrell、Ted Hardieに感謝します。

Author's Address

著者のアドレス

Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany

Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ

   Email: julian.reschke@greenbytes.de
   URI:   http://greenbytes.de/tech/webdav/