1. 序論
~HTTPにおける`内容~符号法$は、 圧縮や完全性~検査~用などに，`~payload$の符号化法を許容する（ `7231-3.1.2$rfc ）。 特に， "`gzip$c" 内容~符号法は、 応答~message内に送信される~payload~data用に広範に利用されている。 ◎ 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.
`内容~符号法$は、 要請~message内でも利用できる。 しかしながら，その発見性は応答~message程ではない。 この文書は、 要請~内で~supportされる内容~符号法を指示するために，~HTTP `Accept-Encoding$h ~headerを応答~内での利用~用に拡張する。 加えて、 状態s~code `415$st の定義を［ 適切なときには `Accept-Encoding$h ~headerを内包することを推奨する ］ように更新する。 ◎ 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.
2. 表記規約
この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ 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].
この文書は、 基底~HTTP仕様 — `7230-2$rfc, `7231-3.1.2$rfc — に定義される各種用語を再利用する ◎ This document reuses terminology defined in the base HTTP specifications, namely Section 2 of [RFC7230] and Section 3.1.2 of [RFC7231].
3. 応答~内での `Accept-Encoding^h ~headerの利用-法
`Accept-Encoding$h は、 `RFC7231$r にて要請~headerのみとして定義されている。 ◎ Section 5.3.4 of [RFC7231] defines "Accept-Encoding" as a request header field only.
この仕様は、 応答~headerにも `Accept-Encoding^h を許容するよう，その定義を拡げる。 応答~内に在るときは、［ 資源は，当の応答が応対した要請にて受容する用意があった`内容~符号法$たち ］を指示する。 その `field-value$p が "`identity^c" のみを包含する場合、 ~supportされる内容~符号法は無かったことを含意する。 ◎ 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.
この情報は、 当の応答が応対した要請に特有であることに注意。 ~supportされる符号化法の集合は、 同じ~server上の他の資源~用のそれとは異なるかもしれない。 また、 時間~越しに変化したり， 要請の他の側面（`要請~method$など）に依存することもある。 ◎ 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).
状態s~code `415$st は、［ ~MIME型, `内容~符号法$ ］のどちらに関係する問題にも適用するものと定義されている。 `RFC7231$r ◎ 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.
~supportしない内容~符号法に因り要請に対し失敗した~serverは、 `415$st0 で応答する~OUGHT。 加えて、 その応答~内に `Accept-Encoding$h ~headerを内包して，~clientが［ 当の課題は［ 内容~符号法, ~MIME型 ］のどちらに関係するか ］を判別できるようにする~OUGHT。 ~MIME型に関係する課題との混同を避けるため、 `415^st0 を伴う要請に対し内容~符号法に無関係な事由で失敗した~serverは， `Accept-Encoding$h ~headerを内包してはナラナイ。 ◎ 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.
応答における `Accept-Encoding$h の最も共通的な利用では、 ~clientによる`内容~符号法$の楽観的な利用に対する応答~内に，状態s~code `415$st を伴うことになると予期されている。 しかしながら，この~headerは、［ 未来のヤリトリを最適化するために内容~符号法が~supportされる ］ことを~clientに指示するためにも利用できる。 例えば，［ 要請~payloadは`圧縮~符号法$の利用を正当化するほど十分~大きいものだったが，~clientがそうするのに失敗した ］とき、 `資源$は `2xx$st0 応答~内に この~headerを内包するかもしれない。 ◎ 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.
4. 例
~clientは、 "`compress$c" 内容~符号法（ `7231-3.1.2.1$rfc ）を利用して `POST^m 要請を提出したとする： ◎ A client submits a POST request using the "compress" content coding ([RFC7231], Section 3.1.2.1):
POST /edit/ HTTP/1.1 Host: example.org Content-Type: application/atom+xml;type=entry Content-Encoding: compress ...圧縮された~payload...
"`gzip$c" 内容~符号法しか許容しない~serverは、 この要請を却下する： ◎ The server rejects the request because it only allows the "gzip" content coding:
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
— この資源が要請~内で~supportする内容~符号法は "`gzip^c" のみである。 ◎ This resource only supports the "gzip" content coding in requests.
この時点で，~clientは、 要請を~supportされる "`gzip^c" 内容~符号法で再試行できる。 ◎ At this point, the client can retry the request with the supported "gzip" content coding.
要請~内ではどの内容~符号法も~supportしない~serverは、 次のように回答できる： ◎ 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
— この資源が要請~内で~supportする内容~符号法は無い。 ◎ This resource does not support content codings in requests.
5. 配備~上の考慮点
要請における`内容~符号法$をまだ~supportしない~serverには、 `内容~符号法$を利用する要請に対し失敗することが要求される。 `RFC7231$r は、 この目的に状態s~code `415$st を定義する。 なので、 必要な唯一の変更は，その応答~内に［ 値 "`identity^c" を伴う `Accept-Encoding$h ~header ］を内包することである。 ◎ 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.
何らかの`内容~符号法$を~supportする~serverであっても、 自身が~supportしない内容~符号法を伴う要請に対しては失敗することが要求される。 この仕様に準拠するためには、 ~serverは，問題を通達するために状態s~code `415^st を利用した上で， `Accept-Encoding$h ~headerを内包して 自身が~supportする内容~符号法を列挙する必要がある。 通例的に，~supportする内容~符号法の集合は 静的かつ少数なので、 この~headerを追加することは自明になる~OUGHT。 ◎ 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.
6. ~securityの考慮点
この仕様が追加するのは、 ~supportされる`内容~符号法$の発見, および［ 内容~符号法を~supportしないことに因る要請の失敗 ］に対する診断法に限られる。 そのようなわけで、 新たな~securityの考慮点は導入されない — ~HTTP11／~HTTP2 にて すでに在るもの（ `7231-9$rfc ／ `7540-10$rfc ）は別として。 ◎ 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]).
しかしながら，［ 発見性を上げることと診断法 ］の~~要点は、 要請~内で`内容~符号法$をより容易に利用-可能することである。 これは、 `gzip$c などの`圧縮~符号法$の利用eを~~促すことになるかもしれない — それは、 ~secure~channel越しに利用されるとき， `BREACH$r などの~side-channel攻撃を可能化し得る（ `7540-10.6$rfc ）。 この文書の公表~時点では、 ~HTTP要請における圧縮に BREACH の様な攻撃を適用し得る方法は，明瞭でない。 ◎ 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.
7. ~IANA考慮点
7.1. ~header~registry
~HTTP~headerは、 `BCP90$r にて定義されるとおり， `~message~header~registry＠~IANA-a/message-headers$ の中に登録される。 ◎ HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/message-headers>, as defined by [BCP90].
この文書は、 `Accept-Encoding$h ~headerの定義を更新する。 それに伴い，その~registryの恒久的~message~header名の `Accept-Encoding^h 項には、 この文書の `3$sec への参照が追加された。 ◎ This document updates the definition of the "Accept-Encoding" header field. The "Permanent Message Header Field Names" registry has been updated as follows: • Header Field Name ｜ Protocol ｜ Status ｜ Reference • Accept-Encoding ｜ http ｜ standard ｜ Section 5.3.4 of [RFC7231] and Section 3 of this document
7.2. 状態s~code~registry
~HTTP`状態s~code$は、 `~HTTP状態s~code~registry＠~IANA-a/http-status-codes$ の中に登録される。 ◎ HTTP status codes are registered within the "HTTP Status Codes" registry located at <http://www.iana.org/assignments/http-status-codes>.
この文書は、 状態s~code `415^st0 の定義を更新する。 それに伴い，その~registryにおける `415^st の項には、 この文書の `3$sec への参照が追加された。 ◎ This document updates the definition of the status code 415 (Unsupported Media Type). The "HTTP Status Codes" registry has been updated as follows: • Value Description Reference • 415 Unsupported Media Type • Section 6.5.13 of [RFC7231] and Section 3 of this document
謝辞
~HTTP~WGの参加者である次の方々に：
Thanks go to the Hypertext Transfer Protocol Working Group participants, namely Amos Jeffries, Ben Campbell, Mark Nottingham, Pete Resnick, Stephen Farrell, and Ted Hardie.