Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8336
Category: Standards Track E. Nygren
ISSN: 2070-1721 Akamai Technologies
March 2018
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8336
Category: Standards Track E. Nygren
ISSN: 2070-1721 Akamai Technologies
March 2018
The ORIGIN HTTP/2 Frame
原始HTTP/2帧
Abstract
摘要
This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.
本文档指定HTTP/2的源帧，以指示给定连接上可用的源。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc8336.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8336.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 . . . . . . . . . . . . . . . . . 2
2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 3
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 3
2.3. The Origin Set . . . . . . . . . . . . . . . . . . . . . 4
2.4. Authority, Push, and Coalescing with ORIGIN . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 10
Appendix B. Operational Considerations for Servers . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 3
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 3
2.3. The Origin Set . . . . . . . . . . . . . . . . . . . . . 4
2.4. Authority, Push, and Coalescing with ORIGIN . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 10
Appendix B. Operational Considerations for Servers . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
HTTP/2 [RFC7540] allows clients to coalesce different origins [RFC6454] onto the same connection when certain conditions are met. However, in some cases, a connection is not usable for a coalesced origin, so the 421 (Misdirected Request) status code ([RFC7540], Section 9.1.2) was defined.
HTTP/2[RFC7540]允许客户端在满足某些条件时将不同的源[RFC6454]合并到同一个连接上。但是，在某些情况下，连接不可用于合并原点，因此定义了421（错误定向请求）状态代码（[RFC7540]，第9.1.2节）。
Using a status code in this manner allows clients to recover from misdirected requests, but at the penalty of adding latency. To address that, this specification defines a new HTTP/2 frame type, "ORIGIN", to allow servers to indicate for which origins a connection is usable.
以这种方式使用状态代码允许客户端从错误定向的请求中恢复，但代价是增加延迟。为了解决这个问题，本规范定义了一个新的HTTP/2帧类型“ORIGIN”，以允许服务器指示连接可用于哪个ORIGIN。
Additionally, experience has shown that HTTP/2's requirement to establish server authority using both DNS and the server's certificate is onerous. This specification relaxes the requirement to check DNS when the ORIGIN frame is in use. Doing so has additional benefits, such as removing the latency associated with some DNS lookups.
此外，经验表明，HTTP/2要求同时使用DNS和服务器的证书来建立服务器权限是非常繁重的。本规范放宽了在使用原始帧时检查DNS的要求。这样做还有其他好处，例如消除与某些DNS查找相关的延迟。
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]所述进行解释。
This document defines a new HTTP/2 frame type ([RFC7540], Section 4) called ORIGIN, that allows a server to indicate what origin(s) [RFC6454] the server would like the client to consider as members of the Origin Set (Section 2.3) for the connection within which it occurs.
该文档定义了一种新的HTTP／2帧类型（[RCFC4040]，第4节），称为Origin，它允许服务器指示服务器希望客户端作为其发生的连接的成员（原件集（节2.3））的原点（RC6644]。
The ORIGIN frame type is 0xc (decimal 12) and contains zero or more instances of the Origin-Entry field.
原点帧类型为0xc（十进制12），包含零个或多个原点输入字段实例。
+-------------------------------+-------------------------------+
| Origin-Entry (*) ...
+-------------------------------+-------------------------------+
+-------------------------------+-------------------------------+
| Origin-Entry (*) ...
+-------------------------------+-------------------------------+
An Origin-Entry is a length-delimited string:
原点条目是以长度分隔的字符串：
+-------------------------------+-------------------------------+
| Origin-Len (16) | ASCII-Origin? ...
+-------------------------------+-------------------------------+
+-------------------------------+-------------------------------+
| Origin-Len (16) | ASCII-Origin? ...
+-------------------------------+-------------------------------+
Specifically:
明确地：
Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field.
Origin Len：一个无符号的16位整数，表示ASCII原点字段的长度（以八位字节为单位）。
Origin: An OPTIONAL sequence of characters containing the ASCII serialization of an origin ([RFC6454], Section 6.2) that the sender asserts this connection is or could be authoritative for.
原点：一个可选的字符序列，包含一个原点的ASCII序列化（[RFC6454]，第6.2节），发送方断言此连接是或可能是权威的。
The ORIGIN frame does not define any flags. However, future updates to this specification MAY define flags. See Section 2.2.
原点框架未定义任何标志。但是，此规范的未来更新可能会定义标志。见第2.2节。
The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame can safely ignore it upon receipt.
原始帧是HTTP/2的非关键扩展。不支持此框架的端点可以在收到后安全地忽略它。
When received by an implementing client, it is used to initialize and manipulate the Origin Set (see Section 2.3), thereby changing how the client establishes authority for origin servers (see Section 2.4).
当一个实现客户端接收到它时，它用于初始化和操作源服务器集（参见第2.3节），从而改变客户端为源服务器建立权限的方式（参见第2.4节）。
The ORIGIN frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored.
原始帧必须在流0上发送；任何其他流上的原始帧无效，必须忽略。
Likewise, the ORIGIN frame is only valid on connections with the "h2" protocol identifier or when specifically nominated by the protocol's definition; it MUST be ignored when received on a connection with the "h2c" protocol identifier.
同样，原始帧仅在具有“h2”协议标识符的连接上有效，或者在协议定义特别指定时有效；当在具有“h2c”协议标识符的连接上接收时，必须忽略它。
This specification does not define any flags for the ORIGIN frame, but future updates to this specification (through IETF consensus) might use them to change its semantics. The first four flags (0x1, 0x2, 0x4, and 0x8) are reserved for backwards-incompatible changes; therefore, when any of them are set, the ORIGIN frame containing them MUST be ignored by clients conforming to this specification, unless the flag's semantics are understood. The remaining flags are reserved for backwards-compatible changes and do not affect processing by clients conformant to this specification.
本规范没有为原始帧定义任何标志，但将来对本规范的更新（通过IETF共识）可能会使用它们来更改其语义。前四个标志（0x1、0x2、0x4和0x8）保留用于向后不兼容的更改；因此，当设置其中任何一个标志时，符合本规范的客户端必须忽略包含这些标志的原始框架，除非理解标志的语义。其余标志保留用于向后兼容的更改，不会影响符合此规范的客户端的处理。
The ORIGIN frame describes a property of the connection and therefore is processed hop by hop. An intermediary MUST NOT forward ORIGIN frames. Clients configured to use a proxy MUST ignore any ORIGIN frames received from it.
原始帧描述连接的属性，因此逐跳处理。中间层不得转发原始帧。配置为使用代理的客户端必须忽略从其接收的任何原始帧。
Each ASCII-Origin field in the frame's payload MUST be parsed as an ASCII serialization of an origin ([RFC6454], Section 6.2). If parsing fails, the field MUST be ignored.
帧有效负载中的每个ASCII原点字段必须解析为原点的ASCII序列化（[RFC6454]，第6.2节）。如果解析失败，则必须忽略该字段。
Note that the ORIGIN frame does not support wildcard names (e.g., "*.example.com") in Origin-Entry. As a result, sending ORIGIN when a wildcard certificate is in use effectively disables any origins that are not explicitly listed in the ORIGIN frame(s) (when the client understands ORIGIN).
请注意，原点框不支持原点条目中的通配符名称（例如“*.example.com”）。因此，在使用通配符证书时发送源代码可以有效地禁用源代码框架中未明确列出的任何源代码（当客户端理解源代码时）。
See Appendix A for an illustrative algorithm for processing ORIGIN frames.
有关处理原始帧的说明性算法，请参见附录A。
The set of origins (as per [RFC6454]) that a given connection might be used for is known in this specification as the Origin Set.
给定连接可能用于的原点集（根据[RFC6454]）在本规范中称为原点集。
By default, the Origin Set for a connection is uninitialized. An uninitialized Origin Set means that clients apply the coalescing rules from Section 9.1.1 of [RFC7540].
默认情况下，连接的原点集未初始化。未初始化的原点集意味着客户端应用[RFC7540]第9.1.1节中的合并规则。
When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain an initial origin. The initial origin is composed from:
当客户端首次接收并成功处理原点帧时，连接的原点集被定义为包含初始原点。初始原点由以下部分组成：
o Scheme: "https"
o 方案：“https”
o Host: the value sent in Server Name Indication (SNI) ([RFC6066], Section 3) converted to lower case; if SNI is not present, the remote address of the connection (i.e., the server's IP address)
o 主机：服务器名称指示（SNI）（[RFC6066]，第3节）中发送的值转换为小写；如果SNI不存在，则连接的远程地址（即服务器的IP地址）
o Port: the remote port of the connection (i.e., the server's port)
o 端口：连接的远程端口（即服务器的端口）
The contents of that ORIGIN frame (and subsequent ones) allow the server to incrementally add new origins to the Origin Set, as described in Section 2.2.
如第2.2节所述，该原点框架（以及后续框架）的内容允许服务器向原点集增量添加新原点。
The Origin Set is also affected by the 421 (Misdirected Request) response status code, as defined in [RFC7540], Section 9.1.2. Upon receipt of a response with this status code, implementing clients MUST create the ASCII serialization of the corresponding request's origin (as per [RFC6454], Section 6.2) and remove it from the connection's Origin Set, if present.
原点集还受[RFC7540]第9.1.2节中定义的421（错误定向请求）响应状态代码的影响。收到带有此状态代码的响应后，实现客户端必须创建相应请求的源的ASCII序列化（根据[RFC6454]，第6.2节），并将其从连接的源集中删除（如果存在）。
Note: When sending an ORIGIN frame to a connection that is initialized as an alternative service [RFC7838], the initial Origin Set (Section 2.3) will contain an origin with the appropriate scheme and hostname (since RFC 7838 specifies that the origin's hostname be sent in SNI). However, it is possible that the port will be different than that of the intended origin, since the initial Origin Set is calculated using the actual port in use, which can be different for the alternative service. In this case, the intended origin needs to be sent in the ORIGIN frame explicitly.
注意：当向初始化为替代服务[RFC7838]的连接发送原点帧时，初始原点集（第2.3节）将包含具有适当方案和主机名的原点（因为RFC 7838指定以SNI发送原点的主机名）。但是，由于初始原点集是使用实际使用的端口来计算的，因此该端口可能与预期原点不同，对于替代服务，实际使用的端口可能不同。在这种情况下，需要在origin帧中显式发送预期的origin。
For example, a client making requests for "https://example.com" is directed to an alternative service at ("h2", "x.example.net", "8443"). If this alternative service sends an ORIGIN frame, the initial origin will be "https://example.com:8443". The client will not be able to use the alternative service to make requests for "https://example.com" unless that origin is explicitly included in the ORIGIN frame.
例如，客户机请求“https://example.com指向位于（“h2”、“x.example.net”、“8443”）的替代服务。如果此替代服务发送原点帧，则初始原点将为“https://example.com:8443". 客户端将无法使用替代服务请求“https://example.com“除非该原点明确包含在原点框中。
Section 10.1 of [RFC7540] uses both DNS and the presented Transport Layer Security (TLS) certificate to establish the origin server(s) that a connection is authoritative for, just as HTTP/1.1 does in [RFC7230].
[RFC7540]的第10.1节使用DNS和提供的传输层安全（TLS）证书来建立连接的授权源服务器，就像[RFC7230]中的HTTP/1.1一样。
Furthermore, Section 9.1.1 of [RFC7540] explicitly allows a connection to be used for more than one origin server, if it is authoritative. This affects what responses can be considered authoritative, both for direct responses to requests and for server push (see [RFC7540], Section 8.2.2). Indirectly, it also affects what requests will be sent on a connection, since clients will generally only send requests on connections that they believe to be authoritative for the origin in question.
此外，[RFC7540]第9.1.1节明确允许一个连接用于多个源服务器（如果是权威的）。这会影响对请求的直接响应和服务器推送的权威响应（请参见[RFC7540]，第8.2.2节）。它还间接地影响将在连接上发送的请求，因为客户端通常只在其认为对所讨论的源具有权威性的连接上发送请求。
Once an Origin Set has been initialized for a connection, clients that implement this specification use it to help determine what the connection is authoritative for. Specifically, such clients MUST NOT consider a connection to be authoritative for an origin not present in the Origin Set, and they SHOULD use the connection for all requests to origins in the Origin Set for which the connection is authoritative, unless there are operational reasons for opening a new connection.
一旦为连接初始化了源集，实现此规范的客户端将使用它来帮助确定连接的授权用途。具体而言，这样的客户端不能考虑连接对于原点集中不存在的源具有权威性，并且它们应该使用连接的权限的源集合中的所有源到源的连接，除非有打开新连接的操作原因。
Note that for a connection to be considered authoritative for a given origin, the server is still required to authenticate with a certificate that passes suitable checks; see Section 9.1.1 of [RFC7540] for more information. This includes verifying that the host matches a "dNSName" value from the certificate "subjectAltName" field (using the rules defined in [RFC2818]; see also [RFC5280], Section 4.2.1.6).
注意，对于被认为是给定源的权威连接，服务器仍然需要使用通过适当检查的证书进行身份验证；详见[RFC7540]第9.1.1节。这包括验证主机是否与证书“subjectAltName”字段中的“dNSName”值匹配（使用[RFC2818]中定义的规则；另请参见[RFC5280]第4.2.1.6节）。
Additionally, clients MAY avoid consulting DNS to establish the connection's authority for new requests to origins in the Origin Set; however, those that do so face new risks, as explained in Section 4.
此外，客户端可能会避免咨询DNS以建立连接的权限，以便对源集中的源进行新请求；然而，如第4节所述，这样做的企业面临新的风险。
Because ORIGIN can change the set of origins a connection is used for over time, it is possible that a client might have more than one viable connection to an origin open at any time. When this occurs, clients SHOULD NOT emit new requests on any connection whose Origin Set is a proper subset of another connection's Origin Set, and they SHOULD close it once all outstanding requests are satisfied.
因为ORIGIN可以随着时间的推移更改连接所使用的源的集合，所以客户机在任何时候都可能有多个到源的可行连接处于打开状态。当发生这种情况时，客户端不应该在其原始集是另一个连接的原始集的适当子集的任何连接上发出新请求，并且应该在满足所有未完成的请求后关闭它。
The Origin Set is unaffected by any alternative services [RFC7838] advertisements made by the server. Advertising an alternative service does not affect whether a server is authoritative.
源集不受服务器发出的任何替代服务[RFC7838]播发的影响。发布替代服务不会影响服务器是否具有权威性。
This specification adds an entry to the "HTTP/2 Frame Type" registry.
此规范向“HTTP/2帧类型”注册表添加一个条目。
o Frame Type: ORIGIN
o 框架类型：原点
o Code: 0xc
o 代码：0xc
o Specification: RFC 8336
o 规格：RFC 8336
Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of attacks. See Section 2.4 for mitigations.
盲目信任原始框架内容的客户端将容易受到大量攻击。缓解措施见第2.4节。
Relaxing the requirement to consult DNS when determining authority for an origin means that an attacker who possesses a valid certificate no longer needs to be on path to redirect traffic to them; instead of modifying DNS, they need only convince the user to visit another website in order to coalesce connections to the target onto their existing connection.
在确定来源的权限时放宽查阅DNS的要求意味着拥有有效证书的攻击者不再需要在路径上重定向流量到他们；他们不需要修改DNS，只需要说服用户访问另一个网站，就可以将与目标的连接合并到他们现有的连接上。
As a result, clients opting not to consult DNS ought to employ some alternative means to establish a high degree of confidence that the certificate is legitimate. For example, clients might skip consulting DNS only if they receive proof of inclusion in a Certificate Transparency log [RFC6962] or if they have a recent Online Certificate Status Protocol (OCSP) response [RFC6960] (possibly using the "status_request" TLS extension [RFC6066]) showing that the certificate was not revoked.
因此，选择不咨询DNS的客户应该采用一些替代方法来建立对证书合法性的高度信任。例如，只有当客户端收到证书透明日志[RFC6962]中包含的证据，或者如果客户端具有最近的在线证书状态协议（OCSP）响应[RFC6960]（可能使用“状态请求”TLS扩展[RFC6066]），表明证书未被吊销，客户端才可能跳过查询DNS。
The Origin Set's size is unbounded by this specification and thus could be used by attackers to exhaust client resources. To mitigate this risk, clients can monitor their state commitment and close the connection if it is too high.
原始集的大小不受此规范的限制，因此攻击者可能会利用它来耗尽客户端资源。为了降低此风险，客户端可以监控其状态承诺，并在连接过高时关闭连接。
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<https://www.rfc-editor.org/info/rfc6066>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<https://www.rfc-editor.org/info/rfc6454>.
[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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，RFC 6962，DOI 10.17487/RFC6962，2013年6月<https://www.rfc-editor.org/info/rfc6962>.
[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, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC7838]诺丁汉，M.，McManus，P.，和J.Reschke，“HTTP替代服务”，RFC 7838，DOI 10.17487/RFC7838，2016年4月<https://www.rfc-editor.org/info/rfc7838>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
The following algorithm illustrates how a client could handle received ORIGIN frames:
以下算法说明了客户端如何处理接收到的原始帧：
1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing.
1. 如果客户端配置为使用代理进行连接，请忽略帧并停止处理。
2. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing.
2. 如果未使用“h2”协议标识符或明确选择此规范的其他协议标识连接，请忽略该帧并停止处理。
3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing.
3. 如果帧出现在流0以外的任何流上，请忽略该帧并停止处理。
4. If any of the flags 0x1, 0x2, 0x4, or 0x8 are set, ignore the frame and stop processing.
4. 如果设置了任何标志0x1、0x2、0x4或0x8，请忽略该帧并停止处理。
5. If no previous ORIGIN frame on the connection has reached this step, initialize the Origin Set as per Section 2.3.
5. 如果连接上没有先前的原点帧达到此步骤，则根据第2.3节初始化原点集。
6. For each "Origin-Entry" in the frame payload:
6. 对于帧有效载荷中的每个“原点条目”：
1. Parse "ASCII-Origin" as an ASCII serialization of an origin ([RFC6454], Section 6.2), and let the result be "parsed_origin". If parsing fails, skip to the next "Origin-Entry".
1. 将“ASCII原点”解析为原点的ASCII序列化（[RFC6454]，第6.2节），并将结果解析为“解析原点”。如果解析失败，请跳到下一个“源条目”。
2. Add "parsed_origin" to the Origin Set.
2. 将“已解析的_原点”添加到原点集。
The ORIGIN frame allows a server to indicate for which origins a given connection ought be used. The set of origins advertised using this mechanism is under control of the server; servers are not obligated to use it or to advertise all origins that they might be able to answer a request for.
ORIGIN框架允许服务器指示应该使用给定连接的哪个ORIGIN。使用此机制播发的源集由服务器控制；服务器没有义务使用它，也没有义务公布它们可能能够回答请求的所有来源。
For example, it can be used to inform the client that the connection is to only be used for the SNI-based origin, by sending an empty ORIGIN frame. Or, a larger number of origins can be indicated by including a payload.
例如，它可以通过发送一个空的原点帧来通知客户端，连接仅用于基于SNI的原点。或者，可以通过包括有效载荷来指示更多的原点。
Generally, this information is most useful to send before sending any part of a response that might initiate a new connection; for example, "Link" response header fields [RFC8288], or links in the response body.
通常，在发送可能启动新连接的响应的任何部分之前，发送此信息最有用；例如，“链接”响应头字段[RFC8288]，或响应正文中的链接。
Therefore, the ORIGIN frame ought be sent as soon as possible on a connection, ideally before any HEADERS or PUSH_PROMISE frames.
因此，应该在连接上尽快发送原始帧，最好是在任何头帧或推送帧之前。
However, if it's desirable to associate a large number of origins with a connection, doing so might introduce end-user-perceived latency, due to their size. As a result, it might be necessary to select a "core" set of origins to send initially, and expand the set of origins the connection is used for with subsequent ORIGIN frames later (e.g., when the connection is idle).
然而，如果希望将大量的来源与连接相关联，那么这样做可能会由于其大小而引入最终用户感知的延迟。因此，可能需要选择一组初始发送的“核心”原点，并在以后（例如，当连接空闲时）扩展连接用于后续原点帧的原点集。
That said, senders are encouraged to include as many origins as practical within a single ORIGIN frame; clients need to make decisions about creating connections on the fly, and if the Origin Set is split across many frames, their behavior might be suboptimal.
也就是说，鼓励发送者在一个单一来源框架内包括尽可能多的来源；客户机需要决定如何动态创建连接，如果原点集被分割到多个帧，则它们的行为可能不太理想。
Senders take note that, as per Section 4, Step 5, of [RFC6454], the values in an ORIGIN header need to be case-normalized before serialization.
发送方注意到，根据[RFC6454]第4节第5步，在序列化之前，需要对原始标头中的值进行大小写规范化。
Finally, servers that host alternative services [RFC7838] will need to explicitly advertise their origins when sending ORIGIN, because the default contents of the Origin Set (as per Section 2.3) do not contain any alternative services' origins, even if they have been used previously on the connection.
最后，托管替代服务[RFC7838]的服务器在发送源站时需要显式公布其源站，因为源站集的默认内容（根据第2.3节）不包含任何替代服务的源站，即使它们以前在连接上使用过。
Authors' Addresses
作者地址
Mark Nottingham
马克诺丁汉
Email: mnot@mnot.net
URI: https://www.mnot.net/
Email: mnot@mnot.net
URI: https://www.mnot.net/
Erik Nygren Akamai Technologies
Erik Nygren Akamai Technologies
Email: erik+ietf@nygren.org
Email: erik+ietf@nygren.org