Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 7694 greenbytes
Category: Standards Track November 2015
ISSN: 2070-1721
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”内容编码广泛用于响应消息中发送的有效负载数据。
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 for use in responses, to indicate the content codings that are supported in requests.
内容编码也可用于请求消息中；然而，可发现性与响应消息不一致。本文档扩展了HTTP“Accept Encoding”头字段以用于响应，以指示请求中支持的内容编码。
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/rfc7694.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7694.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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节），建议在适当时包括“接受编码”头字段。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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节。
Section 5.3.4 of [RFC7231] defines "Accept-Encoding" as a request header field only.
[RFC7231]第5.3.4节仅将“接受编码”定义为请求头字段。
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.
本规范扩展了该定义，允许“接受编码”作为响应头字段。当出现在响应中时，它指示资源在相关请求中愿意接受的内容编码。仅包含“标识”的字段值表示不支持任何内容编码。
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状态响应，并且应该在该响应中包含“接受编码”头字段，从而允许客户端区分与内容编码和媒体类型相关的问题。为了避免与媒体类型相关的问题混淆，由于与内容编码无关的原因导致415状态请求失败的服务器不得包括“接受编码”头字段。
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.
预期响应中最常用的“接受编码”将具有415（不支持的媒体类型）状态代码，以响应客户端对内容编码的乐观使用。但是，header字段也可以用于向客户端指示支持内容编码，以优化未来的交互。例如，当请求负载足够大，足以证明使用压缩编码是正当的，但客户端未能这样做时，资源可能会将其包含在2xx响应中。
A client submits a POST request using the "compress" content coding ([RFC7231], Section 3.1.2.1):
客户使用“压缩”内容编码提交POST请求（[RFC7231]，第3.1.2.1节）：
POST /edit/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Content-Encoding: compress
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
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
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.
此资源不支持请求中的内容编码。
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（不支持的媒体类型）来表示问题，并且必须包括枚举支持的内容编码的“接受编码”头字段。由于受支持的内容编码集通常是静态的，而且很小，因此添加标题字段应该很简单。
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节），当在安全信道上使用压缩编码时，会导致诸如破坏（参见[RFC7540]第10.6节和[Break]）等旁道攻击。在发布时，还不清楚如何将类似破坏的攻击应用于HTTP请求中的压缩。
HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/ message-headers>, as defined by [BCP90].
HTTP头字段在位于的“消息头”注册表中注册<http://www.iana.org/assignments/ 消息头>，由[BCP90]定义。
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 | Protocol | Status | Reference |
| Name | | | |
+-----------------+----------+----------+---------------------------+
| Accept-Encoding | http | standard | Section 5.3.4 of |
| | | | [RFC7231] and Section 3 |
| | | | of this document |
+-----------------+----------+----------+---------------------------+
+-----------------+----------+----------+---------------------------+
| Header Field | Protocol | Status | Reference |
| Name | | | |
+-----------------+----------+----------+---------------------------+
| Accept-Encoding | http | standard | Section 5.3.4 of |
| | | | [RFC7231] and Section 3 |
| | | | of this document |
+-----------------+----------+----------+---------------------------+
HTTP status codes are registered within the "HTTP Status Codes" registry located at <http://www.iana.org/assignments/ http-status-codes>.
HTTP状态代码在位于的“HTTP状态代码”注册表中注册<http://www.iana.org/assignments/ 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 |
+-------+-----------------+-----------------------------------------+
+-------+-----------------+-----------------------------------------+
| Value | Description | Reference |
+-------+-----------------+-----------------------------------------+
| 415 | Unsupported | Section 6.5.13 of [RFC7231] and Section |
| | Media Type | 3 of this document |
+-------+-----------------+-----------------------------------------+
[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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[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>.
[Break]Gluck，Y.，Harris，N.，和A.Prado，“Break:恢复犯罪攻击”，2013年7月<http://breachattack.com/resources/ 违反%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.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本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.
感谢超文本传输协议工作组的参与者，即阿莫斯·杰弗里斯、本·坎贝尔、马克·诺丁汉、皮特·雷斯尼克、斯蒂芬·法雷尔和泰德·哈迪。
Author's Address
作者地址
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/