Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 7838 Akamai
Category: Standards Track P. McManus
ISSN: 2070-1721 Mozilla
J. Reschke
greenbytes
April 2016
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 7838 Akamai
Category: Standards Track P. McManus
ISSN: 2070-1721 Mozilla
J. Reschke
greenbytes
April 2016
HTTP Alternative Services
HTTP替代服务
Abstract
摘要
This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.
本文档指定了HTTP的“替代服务”，该服务允许源站的资源在单独的网络位置授权可用，可能使用不同的协议配置进行访问。
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/rfc7838.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7838.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
1.1. Notational Conventions .....................................3
2. Alternative Services Concepts ...................................3
2.1. Host Authentication ........................................5
2.2. Alternative Service Caching ................................6
2.3. Requiring Server Name Indication ...........................6
2.4. Using Alternative Services .................................6
3. The Alt-Svc HTTP Header Field ...................................8
3.1. Caching Alt-Svc Header Field Values .......................10
4. The ALTSVC HTTP/2 Frame ........................................11
5. The Alt-Used HTTP Header Field .................................13
6. The 421 (Misdirected Request) HTTP Status Code .................13
7. IANA Considerations ............................................13
7.1. Header Field Registrations ................................13
7.2. The ALTSVC HTTP/2 Frame Type ..............................14
7.3. Alt-Svc Parameter Registry ................................14
7.3.1. Procedure ..........................................14
7.3.2. Registrations ......................................15
8. Internationalization Considerations ............................15
9. Security Considerations ........................................15
9.1. Changing Ports ............................................15
9.2. Changing Hosts ............................................15
9.3. Changing Protocols ........................................16
9.4. Tracking Clients Using Alternative Services ...............17
9.5. Confusion regarding Request Scheme ........................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20
1. Introduction ....................................................2
1.1. Notational Conventions .....................................3
2. Alternative Services Concepts ...................................3
2.1. Host Authentication ........................................5
2.2. Alternative Service Caching ................................6
2.3. Requiring Server Name Indication ...........................6
2.4. Using Alternative Services .................................6
3. The Alt-Svc HTTP Header Field ...................................8
3.1. Caching Alt-Svc Header Field Values .......................10
4. The ALTSVC HTTP/2 Frame ........................................11
5. The Alt-Used HTTP Header Field .................................13
6. The 421 (Misdirected Request) HTTP Status Code .................13
7. IANA Considerations ............................................13
7.1. Header Field Registrations ................................13
7.2. The ALTSVC HTTP/2 Frame Type ..............................14
7.3. Alt-Svc Parameter Registry ................................14
7.3.1. Procedure ..........................................14
7.3.2. Registrations ......................................15
8. Internationalization Considerations ............................15
9. Security Considerations ........................................15
9.1. Changing Ports ............................................15
9.2. Changing Hosts ............................................15
9.3. Changing Protocols ........................................16
9.4. Tracking Clients Using Alternative Services ...............17
9.5. Confusion regarding Request Scheme ........................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20
HTTP [RFC7230] conflates the identification of resources with their location. In other words, "http://" and "https://" URIs are used to both name and find things to interact with.
HTTP[RFC7230]将资源的标识与其位置合并。换句话说，“http://”和“https://”URI用于命名和查找要交互的对象。
In some cases, it is desirable to separate identification and location in HTTP; keeping the same identifier for a resource, but interacting with it at a different location on the network.
在某些情况下，需要在HTTP中分离标识和位置；为资源保留相同的标识符，但在网络上的不同位置与其交互。
For example:
例如：
o An origin server might wish to redirect a client to a different server when it is under load, or it has found a server in a location that is more local to the client.
o 源服务器可能希望在负载下将客户端重定向到其他服务器，或者在客户端本地位置找到服务器。
o An origin server might wish to offer access to its resources using a new protocol, such as HTTP/2 [RFC7540], or one using improved security, such as Transport Layer Security (TLS) [RFC5246].
o 源服务器可能希望使用新协议（如HTTP/2[RFC7540]）或使用改进的安全协议（如传输层安全性（TLS）[RFC5246]）提供对其资源的访问。
o An origin server might wish to segment its clients into groups of capabilities, such as those supporting Server Name Indication (SNI) (Section 3 of [RFC6066]), for operational purposes.
o 出于操作目的，源服务器可能希望将其客户端划分为多个功能组，例如支持服务器名称指示（SNI）（RFC6066第3节）的功能组。
This specification defines a new concept in HTTP, "Alternative Services", that allows an origin server to nominate additional means of interacting with it on the network. It defines a general framework for this in Section 2, along with specific mechanisms for advertising their existence using HTTP header fields (Section 3) or HTTP/2 frames (Section 4), plus a way to indicate that an alternative service was used (Section 5).
该规范在HTTP中定义了一个新概念“替代服务”，它允许源服务器指定在网络上与其交互的其他方式。它在第2节中为此定义了一个通用框架，以及使用HTTP头字段（第3节）或HTTP/2帧（第4节）宣传其存在的特定机制，以及指示使用了替代服务的方式（第5节）。
It also endorses the status code 421 (Misdirected Request) (Section 6) that origin servers or their nominated alternatives can use to indicate that they are not authoritative for a given origin, in cases where the wrong location is used.
它还认可状态代码421（错误定向请求）（第6节），在使用错误位置的情况下，源服务器或其指定的替代方案可以使用该状态代码来表明它们对于给定的源站不具有权威性。
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 uses the Augmented BNF defined in [RFC5234] and updated by [RFC7405] along with the "#rule" extension defined in Section 7 of [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and [RFC7234]:
本文件使用[RFC5234]中定义并由[RFC7405]更新的扩充BNF以及[RFC7230]第7节中定义的“#规则”扩展。[RFC5234]、[RFC7230]和[RFC7234]中定义了以下规则：
OWS = <OWS, see [RFC7230], Section 3.2.3>
delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1>
port = <port, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7>
OWS = <OWS, see [RFC7230], Section 3.2.3>
delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1>
port = <port, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7>
This specification defines a new concept in HTTP, the "Alternative Service". When an origin [RFC6454] has resources that are accessible through a different protocol/host/port combination, it is said to have an alternative service available.
该规范在HTTP中定义了一个新概念，即“替代服务”。当源[RFC6454]具有可通过不同协议/主机/端口组合访问的资源时，称其具有可用的替代服务。
An alternative service can be used to interact with the resources on an origin server at a separate location on the network, possibly using a different protocol configuration. Alternative services are considered authoritative for an origin's resources, in the sense of [RFC7230], Section 9.1.
替代服务可用于与网络上单独位置的源服务器上的资源交互，可能使用不同的协议配置。在[RFC7230]第9.1节的意义上，替代服务被认为是源站资源的权威服务。
For example, an origin:
例如，原点：
("http", "www.example.com", "80")
（“http”，“www.example.com”，“80”）
might declare that its resources are also accessible at the alternative service:
可能会声明其资源也可通过替代服务访问：
("h2", "new.example.com", "81")
（“h2”，“new.example.com”，“81”）
By their nature, alternative services are explicitly at the granularity of an origin; they cannot be selectively applied to resources within an origin.
就其性质而言，替代服务的粒度明显与来源相同；它们不能选择性地应用于源中的资源。
Alternative services do not replace or change the origin for any given resource; in general, they are not visible to the software "above" the access mechanism. The alternative service is essentially alternative routing information that can also be used to reach the origin in the same way that DNS CNAME or SRV records define routing information at the name resolution level. Each origin maps to a set of these routes -- the default route is derived from the origin itself and the other routes are introduced based on alternative-service information.
替代服务不会取代或改变任何给定资源的来源；通常，它们对于“高于”访问机制的软件不可见。替代服务本质上是替代路由信息，也可用于到达源站，其方式与DNS CNAME或SRV记录在名称解析级别定义路由信息的方式相同。每个源站映射到一组这些路由——默认路由从源站本身派生，其他路由基于备用服务信息引入。
Furthermore, it is important to note that the first member of an alternative service tuple is different from the "scheme" component of an origin; it is more specific, identifying not only the major version of the protocol being used, but potentially the communication options for that protocol as well.
此外，重要的是要注意，备选服务元组的第一个成员不同于源的“方案”组件；更具体的是，不仅要确定所使用协议的主要版本，还可能确定该协议的通信选项。
This means that clients using an alternative service can change the host, port, and protocol that they are using to fetch resources, but these changes MUST NOT be propagated to the application that is using HTTP; from that standpoint, the URI being accessed and all information derived from it (scheme, host, and port) are the same as before.
这意味着使用替代服务的客户端可以更改用于获取资源的主机、端口和协议，但这些更改不得传播到使用HTTP的应用程序；从这个角度来看，所访问的URI以及从中派生的所有信息（方案、主机和端口）与以前相同。
Importantly, this includes its security context; in particular, when TLS [RFC5246] is used to authenticate, the alternative service will need to present a certificate for the origin's host name, not that of the alternative. Likewise, the Host header field ([RFC7230], Section 5.4) is still derived from the origin, not the alternative service (just as it would if a CNAME were being used).
重要的是，这包括其安全背景；特别是，当使用TLS[RFC5246]进行身份验证时，替代服务将需要提供源主机名的证书，而不是替代主机名的证书。同样，主机头字段（[RFC7230]，第5.4节）仍然是从源代码派生的，而不是从替代服务派生的（就像使用CNAME时一样）。
The changes MAY, however, be made visible in debugging tools, consoles, etc.
但是，这些更改可以在调试工具、控制台等中显示。
Formally, an alternative service is identified by the combination of:
从形式上讲，可通过以下组合确定替代服务：
o An Application Layer Protocol Negotiation (ALPN) protocol name, as per [RFC7301]
o 应用层协议协商（ALPN）协议名称，符合[RFC7301]
o A host, as per [RFC3986], Section 3.2.2
o 主机，根据[RFC3986]第3.2.2节
o A port, as per [RFC3986], Section 3.2.3
o 端口，符合[RFC3986]第3.2.3节的要求
The ALPN protocol name is used to identify the application protocol or suite of protocols used by the alternative service. Note that for the purpose of this specification, an ALPN protocol name implicitly includes TLS in the suite of protocols it identifies, unless specified otherwise in its definition. In particular, the ALPN name "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 over TLS.
ALPN协议名称用于标识替代服务使用的应用程序协议或协议套件。请注意，就本规范而言，除非其定义中另有规定，否则ALPN协议名称在其标识的协议套件中隐式包含TLS。特别是，由[RFC7301]第6节注册的ALPN名称“http/1.1”通过TLS标识http/1.1。
Additionally, each alternative service MUST have a freshness lifetime, expressed in seconds (see Section 2.2).
此外，每个替代服务必须有一个新鲜度生命周期，以秒为单位（见第2.2节）。
There are many ways that a client could discover the alternative service(s) associated with an origin. This document describes two such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the "ALTSVC" HTTP/2 frame type (Section 4).
客户机可以通过多种方式发现与源站关联的替代服务。本文档描述了两种这样的机制：“Alt Svc”HTTP头字段（第3节）和“ALTSVC”HTTP/2帧类型（第4节）。
The remainder of this section describes requirements that are common to alternative services, regardless of how they are discovered.
本节的其余部分描述了替代服务所共有的需求，无论它们是如何发现的。
Clients MUST have reasonable assurances that the alternative service is under control of and valid for the whole origin. This mitigates the attack described in Section 9.2.
客户必须有合理的保证，即替代服务受整个来源地的控制并对其有效。这缓解了第9.2节中描述的攻击。
For the purposes of this document, "reasonable assurances" can be established through use of a TLS-based protocol with the certificate checks defined in [RFC2818]. Clients MAY impose additional criteria for establishing reasonable assurances.
在本文件中，“合理保证”可以通过使用基于TLS的协议以及[RFC2818]中定义的证书检查来建立。客户可以为建立合理的保证规定额外的标准。
For example, if the origin's host is "www.example.com" and an alternative is offered on "other.example.com" with the "h2" protocol, and the certificate offered is valid for "www.example.com", the client can use the alternative. However, if either is offered with the "h2c" protocol, the client cannot use it, because there is no
例如，如果源站的主机是“www.example.com”，并且“other.example.com”上提供了具有“h2”协议的替代方案，并且提供的证书对“www.example.com”有效，则客户端可以使用该替代方案。但是，如果其中一个协议与“h2c”协议一起提供，则客户端无法使用它，因为没有
mechanism (at the time of the publication of this specification) in that protocol to establish the relationship between the origin and the alternative.
（在本规范发布时）在该协议中建立原产地和替代品之间关系的机制。
Mechanisms for discovering alternative services also associate a freshness lifetime with them; for example, the Alt-Svc header field uses the "ma" parameter.
发现替代服务的机制也将新鲜度生命周期与之关联；例如，Alt Svc header字段使用“ma”参数。
Clients can choose to use an alternative service instead of the origin at any time when it is considered fresh; see Section 2.4 for specific recommendations.
客户可以选择使用替代服务，而不是在任何时候，当它被认为是新鲜的起源；具体建议见第2.4节。
Clients with existing connections to an alternative service do not need to stop using it when its freshness lifetime ends; the caching mechanism is intended for limiting how long an alternative service can be used for establishing new connections, not limiting the use of existing ones.
现有连接到替代服务的客户端不需要在其新鲜度生命周期结束时停止使用它；缓存机制旨在限制替代服务可用于建立新连接的时间，而不是限制现有连接的使用。
Alternative services are fully authoritative for the origin in question, including the ability to clear or update cached alternative service entries, extend freshness lifetimes, and any other authority the origin server would have.
替代服务对于所讨论的源服务器是完全权威的，包括清除或更新缓存的替代服务条目、延长新鲜度生存期以及源服务器将拥有的任何其他权限。
When alternative services are used to send a client to the most optimal server, a change in network configuration can result in cached values becoming suboptimal. Therefore, clients SHOULD remove from cache all alternative services that lack the "persist" flag with the value "1" when they detect such a change, when information about network state is available.
当使用替代服务将客户机发送到最佳服务器时，网络配置的更改可能会导致缓存值变得不理想。因此，当客户端检测到这样的更改时，当有关网络状态的信息可用时，应该从缓存中删除所有缺少值为“1”的“persist”标志的替代服务。
A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI). This supports the conservation of IP addresses on the alternative service host.
除非客户端支持TLS服务器名称指示（SNI），否则客户端不得使用基于TLS的替代服务。这支持在备用服务主机上保存IP地址。
Note that the SNI information provided in TLS by the client will be that of the origin, not the alternative (as will the Host HTTP header field value).
请注意，客户机在TLS中提供的SNI信息将是源站的信息，而不是备用信息（主机HTTP头字段值也是如此）。
By their nature, alternative services are OPTIONAL: clients do not need to use them. However, it is advantageous for clients to behave in a predictable way when alternative services are used by servers, to aid in purposes like load balancing.
就其性质而言，替代服务是可选的：客户不需要使用它们。然而，当服务器使用替代服务时，客户机以可预测的方式进行行为是有利的，以帮助实现负载平衡等目的。
Therefore, if a client supporting this specification becomes aware of an alternative service, the client SHOULD use that alternative service for all requests to the associated origin as soon as it is available, provided the alternative service information is fresh (Section 2.2) and the security properties of the alternative service protocol are desirable, as compared to the existing connection. A viable alternative service is then treated in every way as the origin; this includes the ability to advertise alternative services.
因此，如果支持本规范的客户意识到替代服务，则客户应在该替代服务可用时，尽快将该替代服务用于相关来源的所有请求，前提是该替代服务信息是最新的（第2.2节）与现有连接相比，替代服务协议的安全性是可取的。然后，一个可行的替代服务在各个方面都被视为起源；这包括宣传替代服务的能力。
If a client becomes aware of multiple alternative services, it chooses the most suitable according to its own criteria, keeping security properties in mind. For example, an origin might advertise multiple alternative services to notify clients of support for multiple versions of HTTP.
如果客户机意识到多个备选服务，它会根据自己的标准选择最合适的服务，同时牢记安全属性。例如，一个源站可能会公布多个备选服务，以通知客户端支持多个版本的HTTP。
A client configured to use a proxy for a given request SHOULD NOT directly connect to an alternative service for this request, but instead route it through that proxy.
配置为对给定请求使用代理的客户端不应直接连接到此请求的替代服务，而应通过该代理路由它。
When a client uses an alternative service for a request, it can indicate this to the server using the Alt-Used header field (Section 5).
当客户机对请求使用替代服务时，它可以使用Alt Used标头字段（第5节）向服务器指示这一点。
The client does not need to block requests on any existing connection; it can be used until the alternative connection is established. However, if the security properties of the existing connection are weak (for example, cleartext HTTP/1.1), then it might make sense to block until the new connection is fully available in order to avoid information leakage.
客户端不需要阻止任何现有连接上的请求；它可以一直使用，直到建立替代连接。但是，如果现有连接的安全属性很弱（例如，cleartext HTTP/1.1），那么在新连接完全可用之前进行阻止可能是有意义的，以避免信息泄漏。
Furthermore, if the connection to the alternative service fails or is unresponsive, the client MAY fall back to using the origin or another alternative service. Note, however, that this could be the basis of a downgrade attack, thus losing any enhanced security properties of the alternative service. If the connection to the alternative service does not negotiate the expected protocol (for example, ALPN fails to negotiate h2, or an Upgrade request to h2c is not accepted), the connection to the alternative service MUST be considered to have failed.
此外，如果到替代服务的连接失败或没有响应，客户端可能会退回到使用源服务或其他替代服务。但是请注意，这可能是降级攻击的基础，因此会丢失替代服务的任何增强安全属性。如果到替代服务的连接未协商预期协议（例如，ALPN未能协商h2，或不接受到h2c的升级请求），则必须认为到替代服务的连接已失败。
An HTTP(S) origin server can advertise the availability of alternative services to clients by adding an Alt-Svc header field to responses.
HTTP（S）源服务器可以通过在响应中添加Alt Svc头字段，向客户端公布替代服务的可用性。
Alt-Svc = clear / 1#alt-value
clear = %s"clear"; "clear", case-sensitive
alt-value = alternative *( OWS ";" OWS parameter )
alternative = protocol-id "=" alt-authority
protocol-id = token ; percent-encoded ALPN protocol name
alt-authority = quoted-string ; containing [ uri-host ] ":" port
parameter = token "=" ( token / quoted-string )
Alt-Svc = clear / 1#alt-value
clear = %s"clear"; "clear", case-sensitive
alt-value = alternative *( OWS ";" OWS parameter )
alternative = protocol-id "=" alt-authority
protocol-id = token ; percent-encoded ALPN protocol name
alt-authority = quoted-string ; containing [ uri-host ] ":" port
parameter = token "=" ( token / quoted-string )
The field value consists either of a list of values, each of which indicates one alternative service, or the keyword "clear".
字段值由值列表（每个值表示一个备选服务）或关键字“clear”组成。
A field value containing the special value "clear" indicates that the origin requests all alternatives for that origin to be invalidated (including those specified in the same response, in case of an invalid reply containing both "clear" and alternative services).
包含特殊值“clear”的字段值表示源站请求使该源站的所有备选方案无效（包括同一响应中指定的备选方案，如果无效回复同时包含“clear”和备选服务）。
ALPN protocol names are octet sequences with no additional constraints on format. Octets not allowed in tokens ([RFC7230], Section 3.2.6) MUST be percent-encoded as per Section 2.1 of [RFC3986]. Consequently, the octet representing the percent character "%" (hex 25) MUST be percent-encoded as well.
ALPN协议名称是八位字节序列，没有额外的格式限制。令牌中不允许的八位字节（[RFC7230]，第3.2.6节）必须按照[RFC3986]第2.1节进行百分比编码。因此，表示百分比字符“%”（十六进制25）的八位字节也必须进行百分比编码。
In order to have precisely one way to represent any ALPN protocol name, the following additional constraints apply:
为了精确地用一种方法表示任何ALPN协议名称，以下附加约束适用：
1. Octets in the ALPN protocol name MUST NOT be percent-encoded if they are valid token characters except "%", and
1. 如果ALPN协议名称中的八位字节是除“%”之外的有效令牌字符，则不能对其进行百分比编码，并且
2. When using percent-encoding, uppercase hex digits MUST be used.
2. 使用百分比编码时，必须使用大写十六进制数字。
With these constraints, recipients can apply simple string comparison to match protocol identifiers.
有了这些约束，收件人可以应用简单的字符串比较来匹配协议标识符。
The "alt-authority" component consists of an OPTIONAL uri-host ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port number.
“alt authority”组件由一个可选的uri主机（[RFC3986]第3.2.2节中的“主机”）、一个冒号（“：”）和一个端口号组成。
For example:
例如：
Alt-Svc: h2=":8000"
Alt-Svc: h2=":8000"
This indicates the "h2" protocol ([RFC7540]) on the same host using the indicated port 8000.
这表示同一主机上使用所示端口8000的“h2”协议（[RFC7540]）。
An example involving a change of host:
涉及更换主机的示例：
Alt-Svc: h2="new.example.org:80"
Alt-Svc: h2="new.example.org:80"
This indicates the "h2" protocol on the host "new.example.org", running on port 80. Note that the "quoted-string" syntax needs to be used because ":" is not an allowed character in "token".
这表示主机“new.example.org”上运行在端口80上的“h2”协议。请注意，需要使用“带引号的字符串”语法，因为“：”不是“令牌”中允许的字符。
Examples for protocol name escaping:
协议名称转义示例：
+--------------------+-------------+---------------------+
| ALPN protocol name | protocol-id | Note |
+--------------------+-------------+---------------------+
| h2 | h2 | No escaping needed |
+--------------------+-------------+---------------------+
| w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
+--------------------+-------------+---------------------+
| x%y | x%25y | "%" needs escaping |
+--------------------+-------------+---------------------+
+--------------------+-------------+---------------------+
| ALPN protocol name | protocol-id | Note |
+--------------------+-------------+---------------------+
| h2 | h2 | No escaping needed |
+--------------------+-------------+---------------------+
| w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
+--------------------+-------------+---------------------+
| x%y | x%25y | "%" needs escaping |
+--------------------+-------------+---------------------+
Alt-Svc MAY occur in any HTTP response message, regardless of the status code. Note that recipients of Alt-Svc can ignore the header field (and are required to in some situations; see Sections 2.1 and 6).
Alt Svc可能出现在任何HTTP响应消息中，而与状态代码无关。请注意，Alt Svc的收件人可以忽略标题字段（在某些情况下需要忽略标题字段；请参见第2.1节和第6节）。
The Alt-Svc field value can have multiple values:
Alt Svc字段值可以有多个值：
Alt-Svc: h2="alt.example.com:8000", h2=":443"
Alt-Svc: h2="alt.example.com:8000", h2=":443"
When multiple values are present, the order of the values reflects the server's preference (with the first value being the most preferred alternative).
当存在多个值时，值的顺序反映服务器的首选项（第一个值是最首选的替代项）。
The value(s) advertised by Alt-Svc can be used by clients to open a new connection to an alternative service. Subsequent requests can start using this new connection immediately or can continue using the existing connection while the new connection is created.
Alt Svc公布的值可供客户端用于打开到替代服务的新连接。后续请求可以立即开始使用此新连接，也可以在创建新连接时继续使用现有连接。
When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC frame (Section 4). A single ALTSVC frame can be sent for a connection; a new frame is not needed for every request. Note that, despite this recommendation, Alt-Svc header fields remain valid in responses delivered over HTTP/2.
当使用HTTP/2（[RFC7540]）时，服务器应改为发送ALTSVC帧（第4节）。可以为连接发送单个ALTSVC帧；并非每个请求都需要新的帧。请注意，尽管有此建议，Alt Svc头字段在通过HTTP/2交付的响应中仍然有效。
Each "alt-value" is followed by an OPTIONAL semicolon-separated list of additional parameters, each such "parameter" comprising a name and a value.
每个“alt值”后面都有一个可选的分号分隔的附加参数列表，每个“参数”包括一个名称和一个值。
This specification defines two parameters: "ma" and "persist", defined in Section 3.1. Unknown parameters MUST be ignored. That is, the values (alt-value) they appear in MUST be processed as if the unknown parameter was not present.
本规范定义了第3.1节中定义的两个参数：“ma”和“persist”。必须忽略未知参数。也就是说，它们出现在中的值（alt值）必须像未知参数不存在一样进行处理。
New parameters can be defined in extension specifications (see Section 7.3 for registration details).
可在扩展规范中定义新参数（注册详情见第7.3节）。
Note that all field elements that allow "quoted-string" syntax MUST be processed as per Section 3.2.6 of [RFC7230].
请注意，所有允许“引用字符串”语法的字段元素必须按照[RFC7230]第3.2.6节进行处理。
When an alternative service is advertised using Alt-Svc, it is considered fresh for 24 hours from generation of the message. This can be modified with the "ma" (max-age) parameter.
当使用Alt Svc发布替代服务时，从消息生成起24小时内该服务被视为新服务。这可以通过“ma”（最大年龄）参数进行修改。
Syntax:
语法：
ma = delta-seconds; see [RFC7234], Section 1.2.1
ma=增量秒；见[RFC7234]，第1.2.1节
The delta-seconds value indicates the number of seconds since the response was generated for which the alternative service is considered fresh.
delta seconds值表示自生成响应以来，替代服务被视为新服务的秒数。
Alt-Svc: h2=":443"; ma=3600
Alt-Svc: h2=":443"; ma=3600
See Section 4.2.3 of [RFC7234] for details on determining the response age.
有关确定响应时间的详细信息，请参见[RFC7234]第4.2.3节。
For example, a response:
例如，响应：
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=600
Age: 30
Alt-Svc: h2=":8000"; ma=60
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=600
Age: 30
Alt-Svc: h2=":8000"; ma=60
indicates that an alternative service is available and usable for the next 60 seconds. However, the response has already been cached for 30 seconds (as per the Age header field value); therefore, the alternative service is only fresh for the 30 seconds from when this response was received, minus estimated transit time.
表示替代服务在接下来的60秒内可用。但是，响应已经缓存了30秒（根据年龄标头字段值）；因此，替代服务仅在收到此响应后的30秒内是新的，减去估计的传输时间。
Note that the freshness lifetime for HTTP caching (here, 600 seconds) does not affect caching of Alt-Svc values.
请注意，HTTP缓存的刷新生存期（此处为600秒）不会影响Alt Svc值的缓存。
When an Alt-Svc response header field is received from an origin, its value invalidates and replaces all cached alternative services for that origin.
当从源站接收到Alt Svc响应头字段时，其值将使该源站的所有缓存替代服务失效并替换。
By default, cached alternative services will be cleared when the client detects a network change. Alternative services that are intended to be longer lived (such as those that are not specific to the client access network) can carry the "persist" parameter with a value "1" as a hint that the service is potentially useful beyond a network configuration change.
默认情况下，当客户端检测到网络更改时，缓存的替代服务将被清除。预期寿命更长的替代服务（例如，那些不是特定于客户端访问网络的服务）可以携带值为“1”的“persist”参数，作为该服务在网络配置更改之外可能有用的提示。
Syntax:
语法：
persist = "1"
persist = "1"
For example:
例如：
Alt-Svc: h2=":443"; ma=2592000; persist=1
Alt-Svc: h2=":443"; ma=2592000; persist=1
This specification only defines a single value for "persist". Clients MUST ignore "persist" parameters with values other than "1".
本规范仅为“persist”定义了一个值。客户端必须忽略值不是“1”的“persist”参数。
See Section 2.2 for general requirements on caching alternative services.
有关缓存替代服务的一般要求，请参见第2.2节。
The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the availability of an alternative service to an HTTP/2 client.
ALTSVC HTTP/2框架（[RFC7540]，第4节）向HTTP/2客户机通告替代服务的可用性。
The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of [RFC7540]).
ALTSVC框架是HTTP/2的非关键扩展。不支持此框架的端点将忽略它（根据[RFC7540]第4.1节中定义的扩展性规则）。
An ALTSVC frame from a server to a client on a stream other than stream 0 indicates that the conveyed alternative service is associated with the origin of that stream.
在流0以外的流上从服务器到客户端的ALTSVC帧表示传送的替代服务与该流的源相关联。
An ALTSVC frame from a server to a client on stream 0 indicates that the conveyed alternative service is associated with the origin contained in the Origin field of the frame. An association with an origin that the client does not consider authoritative for the current connection MUST be ignored.
流0上从服务器到客户机的ALTSVC帧表示传送的替代服务与该帧的origin字段中包含的origin相关联。与客户端对于当前连接不考虑权威的起源的关联必须被忽略。
The ALTSVC frame type is 0xa (decimal 10).
ALTSVC帧类型为0xa（十进制10）。
+-------------------------------+-------------------------------+
| Origin-Len (16) | Origin? (*) ...
+-------------------------------+-------------------------------+
| Alt-Svc-Field-Value (*) ...
+---------------------------------------------------------------+
+-------------------------------+-------------------------------+
| Origin-Len (16) | Origin? (*) ...
+-------------------------------+-------------------------------+
| Alt-Svc-Field-Value (*) ...
+---------------------------------------------------------------+
ALTSVC Frame Payload
帧有效载荷
The ALTSVC frame contains the following fields:
ALTSVC框架包含以下字段：
Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.
原点Len：一个无符号的16位整数，表示原点字段的长度（以八位字节为单位）。
Origin: An OPTIONAL sequence of characters containing the ASCII serialization of an origin ([RFC6454], Section 6.2) to which the alternative service is applicable.
原点：可选的字符序列，包含适用于替代服务的原点的ASCII序列化（[RFC6454]，第6.2节）。
Alt-Svc-Field-Value: A sequence of octets (length determined by subtracting the length of all preceding fields from the frame length) containing a value identical to the Alt-Svc field value defined in Section 3 (ABNF production "Alt-Svc").
Alt Svc字段值：八位字节序列（长度由帧长度减去前面所有字段的长度确定），包含与第3节（ABNF生产“Alt Svc”）中定义的Alt Svc字段值相同的值。
The ALTSVC frame does not define any flags.
ALTSVC帧不定义任何标志。
The ALTSVC frame is intended for receipt by clients. A device acting as a server MUST ignore it.
ALTSVC框架用于客户端接收。作为服务器的设备必须忽略它。
An ALTSVC frame on stream 0 with empty (length 0) "Origin" information is invalid and MUST be ignored. An ALTSVC frame on a stream other than stream 0 containing non-empty "Origin" information is invalid and MUST be ignored.
流0上具有空（长度0）“原点”信息的ALTSVC帧无效，必须忽略。流0以外的流上包含非空“原点”信息的ALTSVC帧无效，必须忽略。
The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in ALTSVC frames in forming new ALTSVC frames to send to its own clients.
ALTSVC帧逐跳处理。中间层不能转发ALTSVC帧，尽管它可以使用ALTSVC帧中包含的信息来形成新的ALTSVC帧以发送给自己的客户端。
Receiving an ALTSVC frame is semantically equivalent to receiving an Alt-Svc header field. As a result, the ALTSVC frame causes alternative services for the corresponding origin to be replaced. Note that it would be unwise to mix the use of Alt-Svc header fields with the use of ALTSVC frames, as the sequence of receipt might be hard to predict.
接收ALTSVC帧在语义上等同于接收Alt Svc头字段。因此，ALTSVC帧会导致替换相应原点的替代服务。请注意，将Alt Svc头字段的使用与ALTSVC帧的使用混用是不明智的，因为接收顺序可能很难预测。
The Alt-Used header field is used in requests to identify the alternative service in use, just as the Host header field (Section 5.4 of [RFC7230]) identifies the host and port of the origin.
Alt Used header字段用于在请求中标识正在使用的替代服务，正如Host header字段（RFC7230的第5.4节）标识源主机和端口一样。
Alt-Used = uri-host [ ":" port ]
Alt Used=uri主机[“：”端口]
Alt-Used is intended to allow alternative services to detect loops, differentiate traffic for purposes of load balancing, and generally to ensure that it is possible to identify the intended destination of traffic, since introducing this information after a protocol is in use has proven to be problematic.
使用Alt的目的是允许替代服务检测循环，区分流量以实现负载平衡，并且通常是为了确保能够识别流量的预期目的地，因为在使用协议后引入此信息已被证明是有问题的。
When using an alternative service, clients SHOULD include an Alt-Used header field in all requests.
当使用替代服务时，客户端应在所有请求中包含Alt Used标头字段。
For example:
例如：
GET /thing HTTP/1.1 Host: origin.example.com Alt-Used: alternate.example.net
GET/thing HTTP/1.1 Host:origin.example.com Alt Used:alternate.example.net
The 421 (Misdirected Request) status code is defined in Section 9.1.2 of [RFC7540] to indicate that the current server instance is not authoritative for the requested resource. This can be used to indicate that an alternative service is not authoritative; see Section 2).
[RFC7540]第9.1.2节中定义了421（定向错误的请求）状态代码，以表明当前服务器实例对请求的资源不具有权威性。这可用于指示替代服务不具有权威性；见第2节）。
Clients receiving 421 (Misdirected Request) from an alternative service MUST remove the corresponding entry from its alternative service cache (see Section 2.2) for that origin. Regardless of the idempotency of the request method, they MAY retry the request, either at another alternative server, or at the origin.
从替代服务接收421（定向错误的请求）的客户端必须从该源的替代服务缓存（参见第2.2节）中删除相应的条目。无论请求方法的幂等性如何，它们都可以在另一个备用服务器或源服务器上重试请求。
An Alt-Svc header field in a 421 (Misdirected Request) response MUST be ignored.
必须忽略421（定向错误的请求）响应中的Alt Svc标头字段。
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<https://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their associated registry entries have been added according to the permanent registrations below (see [BCP90]):
本文档定义了以下HTTP头字段，因此已根据下面的永久注册添加了相关的注册表项（请参见[BCP90]）：
+-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+------------+
| Alt-Svc | http | standard | Section 3 |
| Alt-Used | http | standard | Section 5 |
+-------------------+----------+----------+------------+
+-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+------------+
| Alt-Svc | http | standard | Section 3 |
| Alt-Used | http | standard | Section 5 |
+-------------------+----------+----------+------------+
The change controller is: "IETF (iesg@ietf.org) -- Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)——互联网工程任务组”。
This document registers the ALTSVC frame type in the "HTTP/2 Frame Type" registry ([RFC7540], Section 11.2).
本文档在“HTTP/2帧类型”注册表（[RFC7540]，第11.2节）中注册ALTSVC帧类型。
Frame Type: ALTSVC
帧类型：ALTSVC
Code: 0xa
代码：0xa
Specification: Section 4 of this document
规范：本文件第4节
The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" defines the name space for parameters. It has been created and will be maintained at <http://www.iana.org/assignments/http-alt-svc-parameters>.
“超文本传输协议（HTTP）Alt Svc参数注册表”定义参数的名称空间。它已创建，并将在<http://www.iana.org/assignments/http-alt-svc-parameters>.
A registration MUST include the following fields:
注册必须包括以下字段：
o Parameter Name
o 参数名
o Pointer to specification text
o 指向规范文本的指针
Values to be added to this name space require Expert Review (see [RFC5226], Section 4.1).
添加到此名称空间的值需要专家审查（请参见[RFC5226]，第4.1节）。
The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been populated with the registrations below:
“超文本传输协议（HTTP）Alt Svc参数注册表”已填充以下注册：
+-------------------+--------------+
| Alt-Svc Parameter | Reference |
+-------------------+--------------+
| ma | Section 3.1 |
| persist | Section 3.1 |
+-------------------+--------------+
+-------------------+--------------+
| Alt-Svc Parameter | Reference |
+-------------------+--------------+
| ma | Section 3.1 |
| persist | Section 3.1 |
+-------------------+--------------+
An internationalized domain name that appears in either the header field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed using A-labels ([RFC5890], Section 2.3.2.1).
出现在头字段（第3节）或HTTP/2框架（第4节）中的国际化域名必须使用A标签（[RFC5890]，第2.3.2.1节）表示。
Using an alternative service implies accessing an origin's resources on an alternative port, at a minimum. Therefore, an attacker that can inject alternative services and listen at the advertised port is able to hijack an origin. On certain servers, it is normal for users to be able to control some personal pages available on a shared port and also to accept requests on less-privileged ports.
使用替代服务意味着至少在替代端口上访问源站的资源。因此，能够注入替代服务并在播发端口侦听的攻击者能够劫持源站。在某些服务器上，用户可以控制共享端口上可用的某些个人页面，也可以在权限较低的端口上接受请求，这是正常的。
For example, an attacker that can add HTTP response header fields to some pages can redirect traffic for an entire origin to a different port on the same host using the Alt-Svc header field; if that port is under the attacker's control, they can thus masquerade as the HTTP server.
例如，可以向某些页面添加HTTP响应标头字段的攻击者可以使用Alt Svc标头字段将整个源站的流量重定向到同一主机上的不同端口；如果该端口在攻击者的控制下，他们就可以伪装成HTTP服务器。
This risk is mitigated by the requirements in Section 2.1.
第2.1节中的要求缓解了该风险。
On servers, this risk can also be reduced by restricting the ability to advertise alternative services, and restricting who can open a port for listening on that host.
在服务器上，还可以通过限制播发替代服务的能力，以及限制谁可以打开用于侦听该主机的端口来降低这种风险。
When the host is changed due to the use of an alternative service, this presents an opportunity for attackers to hijack communication to an origin.
当主机因使用替代服务而发生更改时，攻击者有机会劫持到源站的通信。
For example, if an attacker can convince a user agent to send all traffic for "innocent.example.org" to "evil.example.com" by successfully associating it as an alternative service, they can masquerade as that origin. This can be done locally (see mitigations in Section 9.1) or remotely (e.g., by an intermediary as a man-in-the-middle attack).
例如，如果攻击者能够通过将“innomy.example.org”的所有流量成功关联为替代服务，从而说服用户代理将其发送到“evil.example.com”，那么他们就可以伪装成该来源。这可以在本地（见第9.1节中的缓解措施）或远程（例如，通过中间人攻击）完成。
This is the reason for the requirement in Section 2.1 that clients have reasonable assurances that the alternative service is under control of and valid for the whole origin; for example, presenting a certificate for the origin proves that the alternative service is authorized to serve traffic for the origin.
这就是第2.1节要求客户合理保证替代服务受控于整个原产地并对其有效的原因；例如，出示原产地证书证明替代服务被授权为原产地提供交通服务。
Note that this assurance is only as strong as the method used to authenticate the alternative service. In particular, when TLS authentication is used to do so, there are well-known exploits to make an attacker's certificate appear as legitimate.
请注意，此保证仅与用于验证替代服务的方法一样强大。特别是，当使用TLS身份验证时，存在一些众所周知的利用漏洞使攻击者的证书看起来合法。
Alternative services could be used to persist such an attack. For example, an intermediary could man-in-the-middle TLS-protected communication to a target and then direct all traffic to an alternative service with a large freshness lifetime so that the user agent still directs traffic to the attacker even when not using the intermediary.
可以使用替代服务来持续此类攻击。例如，中间人可以将受TLS保护的通信发送到目标，然后将所有流量定向到具有较大新鲜度生存期的替代服务，这样即使不使用中间人，用户代理仍会将流量定向到攻击者。
Implementations MUST perform any certificate-pinning validation (such as [RFC7469]) on alternative services just as they would on direct connections to the origin. Implementations might also choose to add other requirements around which certificates are acceptable for alternative services.
实现必须在替代服务上执行任何证书固定验证（如[RFC7469]），就像在直接连接到源服务器上一样。实现还可以选择添加其他要求，围绕这些要求，证书可用于替代服务。
When the ALPN protocol is changed due to the use of an alternative service, the security properties of the new connection to the origin can be different from that of the "normal" connection to the origin, because the protocol identifier itself implies this.
当由于使用替代服务而更改ALPN协议时，到源站的新连接的安全属性可能不同于到源站的“正常”连接的安全属性，因为协议标识符本身暗示了这一点。
For example, if an "https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely, TLS), this violates the expectations for security that the URI scheme implies. Therefore, clients cannot use alternative services blindly, but instead evaluate the option(s) presented to ensure that security requirements and expectations of specifications, implementations, and end users are met.
例如，如果一个“https://”URI有一个不使用某种形式的端到端加密（最有可能是TLS）的协议，这违反了URI方案所暗示的安全性预期。因此，客户不能盲目地使用替代服务，而是评估提供的选项，以确保满足规范、实现和最终用户的安全要求和期望。
Choosing an alternative service implies connecting to a new, server-supplied host name. By using unique names, servers could conceivably track client requests. Such tracking could follow users across multiple networks, when the "persist" flag is used.
选择替代服务意味着连接到服务器提供的新主机名。通过使用唯一的名称，服务器可以跟踪客户机请求。当使用“persist”标志时，这种跟踪可以跟踪多个网络中的用户。
Clients that wish to prevent requests from being correlated can decide not to use alternative services for multiple requests that would not otherwise be allowed to be correlated.
希望阻止请求关联的客户端可以决定不对多个请求使用替代服务，否则这些请求将不允许关联。
In a user agent, any alternative service information MUST be removed when origin-specific data is cleared (typically, when cookies [RFC6265] are cleared).
在用户代理中，当清除源特定数据时（通常，当清除Cookie[RFC6265]时），必须删除任何替代服务信息。
Some server-side HTTP applications make assumptions about security based upon connection context; for example, equating being served upon port 443 with the use of an "https://" URI and the various security properties that implies.
一些服务器端HTTP应用程序根据连接上下文对安全性进行假设；例如，将在端口443上服务等同于使用“https://”URI和暗示的各种安全属性。
This affects not only the security properties of the connection itself, but also the state of the client at the other end of it; for example, a Web browser treats "https://" URIs differently than "http://" URIs in many ways, not just for purposes of protocol handling.
这不仅会影响连接本身的安全属性，还会影响连接另一端的客户端的状态；例如，Web浏览器在许多方面对待“https://”URI与对待“http://”URI的方式不同，而不仅仅是出于协议处理的目的。
Since one of the uses of Alternative Services is to allow a connection to be migrated to a different protocol and port, these applications can become confused about the security properties of a given connection, sending information (for example, cookies and content) that is intended for a secure context (such as an "https://" URI) to a client that is not treating it as one.
由于替代服务的用途之一是允许将连接迁移到不同的协议和端口，因此这些应用程序可能会对给定连接的安全属性感到困惑，从而发送用于安全上下文（例如“https://”URI）的信息（例如cookie和内容）给一个不把它当作一个整体的客户。
This risk can be mitigated in servers by using the URI scheme explicitly carried by the protocol (such as ":scheme" in HTTP/2 or the "absolute form" of the request target in HTTP/1.1) as an indication of security context, instead of other connection properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
通过使用协议显式携带的URI方案（例如HTTP/2中的“：scheme”或HTTP/1.1中请求目标的“绝对形式”）作为安全上下文的指示，而不是其他连接属性（[RFC7540]，第8.1.2.3节和[RFC7230]，第5.3.2节），可以在服务器中减轻此风险。
When the protocol does not explicitly carry the scheme (as is usually the case for HTTP/1.1 over TLS), servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (for example, HTTP).
当协议没有显式地携带该方案时（通常情况下是HTTP/1.1 over TLS），服务器可以通过假设所有请求都具有不安全的上下文，或者通过避免为不安全的方案（例如HTTP）宣传替代服务来减轻这种风险。
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[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>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和S.Emile，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<http://www.rfc-editor.org/info/rfc7301>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <http://www.rfc-editor.org/info/rfc7405>.
[RFC7405]Kyzivat，P.，“ABNF中的区分大小写字符串支持”，RFC 7405，DOI 10.17487/RFC7405，2014年12月<http://www.rfc-editor.org/info/rfc7405>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol version 2", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Pain，R.，和M.Thomson，编辑，“超文本传输协议版本2”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<http://www.rfc-editor.org/info/rfc7469>.
Acknowledgements
致谢
Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and suggestions.
感谢Adam Langley、Bence Beky、Chris Lonvick、Eliot Lear、Erik Nygren、Guy Podjarny、Herve Ruellan、Lucas Pardue、Martin Thomson、Matthew Kerwin、Mike Bishop、Paul Hoffman、Richard Barnes、Richard Bradbury、Stephen Farrell、Stephen Ludin和Will Chan的反馈和建议。
The Alt-Svc header field was influenced by the design of the Alternate-Protocol header field in SPDY.
Alt Svc头字段受SPDY中备用协议头字段设计的影响。
Authors' Addresses
作者地址
Mark Nottingham Akamai
马克·诺丁汉Akamai
Email: mnot@mnot.net
URI: https://www.mnot.net/
Email: mnot@mnot.net
URI: https://www.mnot.net/
Patrick McManus Mozilla
帕特里克·麦克马纳斯·莫齐拉
Email: mcmanus@ducksong.com
URI: https://mozillians.org/u/pmcmanus/
Email: mcmanus@ducksong.com
URI: https://mozillians.org/u/pmcmanus/
Julian F. Reschke greenbytes GmbH
Julian F.Reschke greenbytes有限公司
Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/
Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/