| 互联网工程任务组 (IETF) | J. Reschke |
| 请求评议：7694 | greenbytes |
| 类别：标准轨道 | 2015年11月 |
| ISSN: 2070-1721 |
超文本传输协议 (HTTP) 客户端发起的内容编码
摘要
在 HTTP 中，内容编码允许对有效负载进行编码，例如用于压缩或完整性校验。特别地，"gzip" 内容编码被广泛用于响应消息中发送的有效负载数据。
内容编码也可以用于请求消息；然而，其可发现性并不如响应消息。本文件扩展了 HTTP 的 "Accept-Encoding" 首部字段以用于响应中，表明在请求中支持的内容编码。
本备忘录的状态
这是一个互联网标准轨道文档。
本文件是互联网工程任务组 (IETF) 的成果，代表 IETF 社区的共识。它已获得公开评审，并由互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 5741 第2节。
有关本文档当前状态、任何勘误及如何提供反馈的信息，可从 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.
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. 引言
在 HTTP 中，内容编码允许对有效负载进行编码，例如用于压缩或完整性校验（[RFC7231]， 第 3.1.2 节）。 特别地，“gzip” 内容编码（[RFC7230]， 第 4.2 节）被广泛用于响应消息中发送的有效负载数据。
内容编码也可以用于请求消息；然而，其可发现性不如响应消息。本文件扩展了 HTTP 的 "Accept-Encoding" 首部字段（[RFC7231]， 第 5.3.4 节）以在响应中使用， 用于指示在请求中支持的内容编码。此外，它还更新了状态码 415（Unsupported Media Type， 不支持的媒体类型）（[RFC7231]， 第 6.5.13 节）的定义， 建议在适当时包含 "Accept-Encoding" 首部字段。
2. 符号约定
文中关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、 "RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按 [RFC2119] 的说明来解释。
3. 在响应中使用 'Accept-Encoding' 首部字段
RFC7231 第 5.3.4 节 将 "Accept-Encoding" 定义为仅用于请求的首部字段。
本规范扩展该定义，允许将 "Accept-Encoding" 用作响应首部字段。当它出现在响应中时，表示该资源在关联的请求中愿意接受哪些内容编码。字段值仅包含 "identity" 则意味着不支持任何内容编码。
注意这些信息是针对于关联请求特定的；同一服务器上其他资源支持的编码集合可能不同，并且可能随时间变化或取决于请求的其他方面（例如请求方法）。
RFC7231 第 6.5.13 节 将状态码 415（Unsupported Media Type）定义为适用于与媒体类型和内容编码相关的问题。
因不受支持的内容编码而导致请求失败的服务器应当使用 415 状态响应，并且应当在该响应中包含 "Accept-Encoding" 首部字段，便于客户端区分与内容编码相关的问题与媒体类型相关的问题。为避免与媒体类型相关的问题混淆，服务器若因与内容编码无关的原因返回 415，则 不得 在响应中包含 "Accept-Encoding" 首部字段。
预期在响应中使用 "Accept-Encoding" 最常见的情形是与 415（Unsupported Media Type）状态码一起，用于响应客户端对请求中乐观使用的内容编码失败的情况。然而，该首部字段也可用于向客户端指示支持哪些内容编码，以优化未来的交互。例如，当请求有效负载足够大以值得使用压缩编码但客户端未使用时，资源可能在 2xx 响应中包含该字段。
4. 示例
客户端提交了一个使用 "compress" 内容编码的 POST 请求（[RFC7231]， 第 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
This resource only supports the "gzip" content coding in requests.
此时，客户端可以使用受支持的 "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
This resource does not support content codings in requests.
5. 部署注意事项
不支持请求中内容编码的服务器已被要求对使用内容编码的请求返回失败。RFC7231 第 6.5.13 节 为此目的定义了 415 状态码，因此唯一需要的更改是在该响应中包含值为 "identity" 的 "Accept-Encoding" 首部字段。
支持某些内容编码的服务器也被要求对不受支持的内容编码的请求返回失败。为了符合本规范，服务器需要使用状态码 415 来标识问题，并且必须在响应中包含列举所支持内容编码的 "Accept-Encoding" 首部字段。由于支持的内容编码集合通常是静态且较小的，添加该首部字段应该是很容易的。
6. 安全性注意事项
本规范仅增加了对支持的内容编码的发现以及因不受支持的内容编码导致请求失败时的诊断。因此，它并未引入超出 HTTP/1.1（见 第 9 节） 与 HTTP/2（见 第 10 节）中已存在的安全注意事项之外的新问题。
不过，更好的可发现性和诊断旨在使在请求中使用内容编码更容易。这可能导致对像 gzip 这样的压缩编码的使用增加（参见 RFC7230 第 4.2 节），而当在安全通道上使用时，可能会使侧信道攻击（例如 BREACH）成为可能（参见 RFC7540 第 10.6 节 与 [BREACH]）。在本文件发表时，尚不清楚如何将类 BREACH 的攻击应用于 HTTP 请求中的压缩。
7. IANA 注意事项
7.1. 首部字段注册表
HTTP 首部字段在位于 <http://www.iana.org/assignments/message-headers> 的 “Message Headers” 注册表中注册，该注册表由 [BCP90] 定义。
本文件更新了 "Accept-Encoding" 首部字段的定义。“永久消息首部字段名”注册表已按如下方式更新：
| Header Field Name | Protocol | Status | Reference |
|---|---|---|---|
| Accept-Encoding | http | standard | RFC7231 第 5.3.4 节 与本文件第 第 3 节 |
7.2. 状态码注册表
HTTP 状态码在位于 <http://www.iana.org/assignments/http-status-codes> 的 “HTTP Status Codes” 注册表中注册。
本文件更新了状态码 415（Unsupported Media Type）的定义。“HTTP Status Codes” 注册表已按如下方式更新：
| Value | Description | Reference |
|---|---|---|
| 415 | Unsupported Media Type | RFC7231 第 6.5.13 节 与本文件第 第 3 节 |
8. 参考文献
8.1. 规范性参考文献
- [RFC2119]
- Bradner, S.，“Key words for use in RFCs to Indicate Requirement Levels”，BCP 14, RFC 2119, March 1997。
- [RFC7230]
- Fielding, R., Ed. 和 J. Reschke, Ed.，“Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”，RFC 7230, June 2014。
- [RFC7231]
- Fielding, R., Ed. 和 J. Reschke, Ed.，“Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”，RFC 7231, June 2014。
8.2. 补充性参考文献
- [BCP90]
- Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”，BCP 90, RFC 3864, September 2004。
- [BREACH]
- Gluck, Y., Harris, N., and A. Prado, “BREACH: Reviving the CRIME Attack”，July 2013。
- [RFC7540]
- Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”，RFC 7540, May 2015。
致谢
感谢超文本传输协议工作组的参与者：Amos Jeffries、Ben Campbell、Mark Nottingham、Pete Resnick、Stephen Farrell 和 Ted Hardie。