Internet Engineering Task Force (IETF) K. Oku
Request for Comments: 8297 Fastly
Category: Experimental December 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Oku
Request for Comments: 8297 Fastly
Category: Experimental December 2017
ISSN: 2070-1721
An HTTP Status Code for Indicating Hints
用于指示提示的HTTP状态代码
Abstract
摘要
This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.
此备忘录引入了一个信息性HTTP状态代码，可用于传递提示，帮助客户机为处理最终响应做好准备。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8297.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8297.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. HTTP Status Code 103: Early Hints . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. HTTP Status Code 103: Early Hints . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use, for example, rendering HTML by a web browser. Having such links available to the client as early as possible helps to minimize perceived latency.
HTTP响应通常包含指向外部资源的链接，这些资源在使用之前需要获取，例如，通过web浏览器呈现HTML。尽早将此类链接提供给客户端有助于将感知的延迟降至最低。
The "preload" [Preload] link relation can be used to convey such links in the Link header field of an HTTP response. However, it is not always possible for an origin server to generate the header block of a final response immediately after receiving a request. For example, the origin server might delegate a request to an upstream HTTP server running at a distant location, or the status code might depend on the result of a database query.
“preload”[preload]链接关系可用于在HTTP响应的链接头字段中传递此类链接。但是，源服务器并非总是能够在收到请求后立即生成最终响应的头块。例如，源服务器可能会将请求委托给运行在远程位置的上游HTTP服务器，或者状态代码可能取决于数据库查询的结果。
The dilemma here is that even though it is preferable for an origin server to send some header fields as soon as it receives a request, it cannot do so until the status code and the full header fields of the final HTTP response are determined.
这里的困境是，即使源服务器最好在收到请求后立即发送一些头字段，但在确定最终HTTP响应的状态代码和完整头字段之前，它不能这样做。
HTTP/2 [RFC7540] server push can accelerate the delivery of resources, but only resources for which the server is authoritative. The other limitation of server push is that the response will be transmitted regardless of whether the client has the response cached. At the cost of spending one extra round trip compared to server push in the worst case, delivering Link header fields in a timely fashion is more flexible and might consume less bandwidth.
HTTP/2[RFC7540]服务器推送可以加速资源的交付，但只能加速服务器授权的资源的交付。服务器推送的另一个限制是，无论客户端是否缓存了响应，都将传输响应。在最坏的情况下，与服务器推送相比，花费一次额外的往返，及时交付链接头字段更灵活，并且可能消耗更少的带宽。
This memo defines a status code for sending an informational response ([RFC7231], Section 6.2) that contains header fields that are likely to be included in the final response. A server can send the informational response containing some of the header fields to help the client start making preparations for processing the final response, and then run time-consuming operations to generate the
本备忘录定义了用于发送信息性响应的状态代码（[RFC7231]，第6.2节），其中包含可能包含在最终响应中的标题字段。服务器可以发送包含某些标头字段的信息性响应，以帮助客户端开始为处理最终响应做准备，然后运行耗时的操作来生成响应
final response. The informational response can also be used by an origin server to trigger HTTP/2 server push at a caching intermediary.
最后答复。源服务器也可以使用信息响应在缓存中介上触发HTTP/2服务器推送。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The 103 (Early Hints) informational status code indicates to the client that the server is likely to send a final response with the header fields included in the informational response.
103（早期提示）信息状态代码向客户机指示服务器可能发送最终响应，其中头字段包含在信息响应中。
Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well. However, there might be cases when this is not desirable, such as when the server learns that the header fields in the 103 (Early Hints) response are not correct before the final response is sent.
通常，服务器还将在最终响应中包含103（早期提示）响应中发送的头字段。然而，可能存在这样的情况，例如当服务器在发送最终响应之前得知103（早期提示）响应中的报头字段不正确时。
A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response. For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response.
在等待最终响应时，客户机可以推测地评估103（早期提示）响应中包含的头字段。例如，客户机可能会识别包含关系类型“preload”的链接头字段值，并开始提取目标资源。但是，这些头字段仅向客户端提供提示；它们不会替换最终响应上的标题字段。
Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed. A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself (e.g., as metadata about the 103 (Early Hints) response).
除了性能优化之外，对103（早期提示）响应的头字段的评估不得影响最终响应的处理方式。客户端不得将103（早期提示）响应头字段解释为应用于信息响应本身（例如，作为103（早期提示）响应的元数据）。
A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response. A client SHOULD NOT interpret the nonexistence of a header field in a 103 (Early Hints) response as a speculation that the header field is unlikely to be part of the final response.
服务器可以使用103（早期提示）响应来仅指示期望在最终响应中找到的一些报头字段。客户端不应将103（早期提示）响应中不存在报头字段解释为推测报头字段不可能是最终响应的一部分。
The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.
下面的示例说明了一个典型的消息交换，它涉及103（早期提示）响应。
Client request:
客户请求：
GET / HTTP/1.1 Host: example.com
GET/HTTP/1.1主机：example.com
Server response:
服务器响应：
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
<!doctype html> [... rest of the response body is omitted from the example ...]
<!doctype html>[…示例中省略了响应正文的其余部分…]
As is the case with any informational response, a server might emit more than one 103 (Early Hints) response prior to sending a final response. This can happen, for example, when a caching intermediary generates a 103 (Early Hints) response based on the header fields of a stale-cached response, and then forwards a 103 (Early Hints) response and a final response that were sent from the origin server in response to a revalidation request.
与任何信息性响应一样，服务器可能会在发送最终响应之前发出多个103（早期提示）响应。例如，当缓存中介基于过时缓存响应的头字段生成103（早期提示）响应，然后转发103（早期提示）响应和从源服务器发送的最终响应以响应重新验证请求时，可能会发生这种情况。
A server MAY emit multiple 103 (Early Hints) responses with additional header fields as new information becomes available while the request is being processed. It does not need to repeat the fields that were already emitted, though it doesn't have to exclude them either. The client can consider any combination of header fields received in multiple 103 (Early Hints) responses when anticipating the list of header fields expected in the final response.
在处理请求时，当新信息变得可用时，服务器可以发出多个103（早期提示）响应以及附加的报头字段。它不需要重复已经发出的字段，尽管也不必排除它们。当预期最终响应中预期的报头字段列表时，客户端可以考虑在多个103（早期提示）响应中接收到的报头字段的任何组合。
The following example illustrates a series of responses that a server might emit. In the example, the server uses two 103 (Early Hints) responses to notify the client that it is likely to send three Link header fields in the final response. Two of the three expected header fields are found in the final response. The other header field is replaced by another Link header field that contains a different value.
下面的示例演示了服务器可能发出的一系列响应。在该示例中，服务器使用两个103（早期提示）响应来通知客户端它可能在最终响应中发送三个链接头字段。在最终响应中可以找到三个预期标头字段中的两个。另一个标题字段被另一个包含不同值的链接标题字段替换。
HTTP/1.1 103 Early Hints
Link: </main.css>; rel=preload; as=style
HTTP/1.1 103 Early Hints
Link: </main.css>; rel=preload; as=style
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel=preload; as=style
Link: </newstyle.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel=preload; as=style
Link: </newstyle.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
<!doctype html> [... rest of the response body is omitted from the example ...]
<!doctype html>[…示例中省略了响应正文的其余部分…]
Some clients might have issues handling a 103 (Early Hints) response, because informational responses are rarely used in reply to requests not including an Expect header field ([RFC7231], Section 5.1.1).
一些客户端在处理103（早期提示）响应时可能会遇到问题，因为信息性响应很少用于响应不包括Expect标头字段的请求（[RFC7231]，第5.1.1节）。
In particular, an HTTP/1.1 client that mishandles an informational response as a final response is likely to consider all responses to the succeeding requests sent over the same connection to be part of the final response. Such behavior might constitute a cross-origin information disclosure vulnerability in case the client multiplexes requests to different origins onto a single persistent connection.
特别地，作为最终响应错误处理信息响应的HTTP／1.1客户端很可能考虑对在相同连接上发送的后续请求的所有响应作为最终响应的一部分。如果客户端将到不同来源的请求多路传输到单个持久连接上，这种行为可能构成跨来源信息泄露漏洞。
Therefore, a server might refrain from sending 103 (Early Hints) responses over HTTP/1.1 unless the client is known to handle informational responses correctly.
因此，服务器可能会避免通过HTTP/1.1发送103（早期提示）响应，除非已知客户端正确处理信息响应。
HTTP/2 clients are less likely to suffer from incorrect framing since handling of the response header fields does not affect how the end of the response body is determined.
HTTP/2客户端不太可能受到错误帧的影响，因为响应头字段的处理不会影响响应体结尾的确定方式。
The following entry has been registered in the "HTTP Status Codes" registry:
以下条目已在“HTTP状态代码”注册表中注册：
o Code: 103
o 代码：103
o Description: Early Hints
o 描述：早期提示
o Specification: RFC 8297 (this document)
o 规范：RFC 8297（本文件）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Preload] Grigorik, I., Ed. and Y. Weiss, Ed., "Preload", W3C Candidate Recommendation, October 2017, <https://www.w3.org/TR/preload/>.
[Preload]Grigorik，I.，Ed.和Y.Weiss，Ed.，“Preload”，W3C候选推荐，2017年10月<https://www.w3.org/TR/preload/>.
Acknowledgements
致谢
Thanks to Tatsuhiro Tsujikawa for coming up with the idea of sending the Link header fields using an informational response.
感谢Tatsuhiro Tsujikawa提出了使用信息响应发送链接头字段的想法。
Mark Nottingham and Willy Tarreau provided substantial help in clarifying the semantics of the status code.
马克·诺丁汉和威利·塔罗在澄清身份代码的语义方面提供了实质性的帮助。
Early stages of the author's work on this document was supported by DeNA Co., Ltd. during his employment there.
在作者受雇于DeNA Co.，Ltd.期间，他在该文件上的早期工作得到了DeNA Co.，Ltd.的支持。
Author's Address
作者地址
Kazuho Oku Fastly
大久和浩斋戒
Email: kazuhooku@gmail.com
Email: kazuhooku@gmail.com