Network Working Group R. Khare
Request for Comments: 2817 4K Associates / UC Irvine
Updates: 2616 S. Lawrence
Category: Standards Track Agranat Systems, Inc.
May 2000
Network Working Group R. Khare
Request for Comments: 2817 4K Associates / UC Irvine
Updates: 2616 S. Lawrence
Category: Standards Track Agranat Systems, Inc.
May 2000
Upgrading to TLS Within HTTP/1.1
升级到HTTP/1.1中的TLS
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address.
本备忘录解释了如何使用HTTP/1.1中的升级机制在现有TCP连接上启动传输层安全性（TLS）。这允许不安全和安全的HTTP通信共享相同的已知端口（在本例中，HTTP:at 80而不是https:at 443）。它还支持“虚拟主机”，因此单个HTTP+TLS服务器可以消除针对单个IP地址上多个主机名的通信量的歧义。
Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.
由于HTTP/1.1[1]将升级定义为逐跳机制，因此本备忘录还记录了跨HTTP代理建立端到端隧道的HTTP连接方法。最后，本备忘录为公共HTTP状态码以及公共或私有升级产品令牌建立了新的IANA注册中心。
This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent).
此备忘录不影响“https”URI方案的当前定义，该方案已经定义了一个单独的命名空间(http://example.org/ 和https://example.org/ 不等同）。
Table of Contents
目录
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5
4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5
5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6
5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6
5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6
5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7
6. Rationale for the use of a 4xx (client error) Status Code . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5
4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5
5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6
5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6
5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6
5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7
6. Rationale for the use of a 4xx (client error) Status Code . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
The historical practice of deploying HTTP over SSL3 [3] has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports.
在SSL3[3]上部署HTTP的历史实践通过唯一的URI方案和TCP端口号将组合与HTTP单独区分开来。方案“http”表示端口80上仅使用http协议，而“https”表示端口443上通过SSL的http协议。为了区分其他应用程序协议（如snews、FTP）的安全使用和非安全使用，也同样要求（在某些情况下授予）并行的已知端口号。这种方法有效地将可用的已知端口数减半。
At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security [6] to an open HTTP connection.
在1997年12月华盛顿特区IETF会议上，应用领域主管和IESG重申，应反对发布并行“安全”端口号的做法。HTTP/1.1升级机制可以将传输层安全[6]应用于开放的HTTP连接。
In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol [7], call for just such a mechanism in order to move ahead in the IETF standards process.
在此后的近两年中，这一提议背后的概念得到了广泛接受，但对于为通用Web浏览实现端口443的替代方案却兴趣不大。事实上，本备忘录中的任何内容都不会影响当前对https:uri的解释。然而，建立在HTTP之上的新的应用程序协议，如Internet打印协议[7]，需要这样一种机制，以便在IETF标准过程中取得进展。
The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single host, an HTTP/1.1 server will use the Host: header to disambiguate the intended web service. As HTTP/1.1 usage has grown more prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion.
升级机制还解决了“虚拟主机”问题。HTTP/1.1服务器将使用host:header来消除预期web服务的歧义，而不是将多个IP地址分配给单个主机。随着HTTP/1.1的使用越来越普遍，越来越多的ISP提供基于名称的虚拟主机，从而延迟了IP地址空间的耗尽。
TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting as well.
TLS（和SSL）受到与HTTP早期版本相同的限制：初始握手不指定预期的主机名，完全依赖于IP地址。在TLS握手中使用明文HTTP/1.1 Upgrade:preamble——根据初始主机：头选择证书——将允许ISP提供基于名称的安全虚拟主机。
TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end connection, optionally including strong mutual authentication, using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the remainder of the connection. The latter is intended to be completely transparent. For example, there is no dependency between TLS's record markers and or certificates and HTTP/1.1's chunked encoding or authentication.
TLS，又称SSL（安全套接字层），使用各种密码系统建立私有端到端连接，可选地包括强相互认证。最初，握手阶段使用三个子脚本来设置记录层、验证端点、设置参数以及报告错误。然后，有一个正在进行的分层记录协议，用于处理连接其余部分的加密、压缩和重新组装。后者旨在完全透明。例如，TLS的记录标记和/或证书与HTTP/1.1的分块编码或身份验证之间没有依赖关系。
Either the client or server can use the HTTP/1.1 [1] Upgrade mechanism (Section 14.42) to indicate that a TLS-secured connection is desired or necessary. This memo defines the "TLS/1.0" Upgrade token, and a new HTTP Status Code, "426 Upgrade Required".
客户机或服务器都可以使用HTTP/1.1[1]升级机制（第14.42节）来表示需要或需要TLS安全连接。此备忘录定义了“TLS/1.0”升级令牌和新的HTTP状态代码“需要426升级”。
Section 3 and Section 4 describe the operation of a directly connected client and server. Intermediate proxies must establish an end-to-end tunnel before applying those operations, as explained in Section 5.
第3节和第4节描述了直接连接的客户机和服务器的操作。如第5节所述，中间代理必须在应用这些操作之前建立端到端通道。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119 [11].
本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照RFC 2119[11]中所述进行解释。
When the client sends an HTTP/1.1 request with an Upgrade header field containing the token "TLS/1.0", it is requesting the server to complete the current HTTP/1.1 request after switching to TLS/1.0.
当客户端发送一个HTTP/1.1请求，其中包含一个包含令牌“TLS/1.0”的升级头字段时，它请求服务器在切换到TLS/1.0后完成当前HTTP/1.1请求。
A client MAY offer to switch to secured operation during any clear HTTP request when an unsecured response would be acceptable:
当可接受不安全响应时，客户端可在任何清除HTTP请求期间提供切换到安全操作：
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
In this case, the server MAY respond to the clear HTTP operation normally, OR switch to secured operation (as detailed in the next section).
在这种情况下，服务器可以正常响应清除HTTP操作，或者切换到安全操作（详见下一节）。
Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message".
请注意，HTTP/1.1[1]指定“每当HTTP/1.1消息中出现升级时，必须在连接头字段（第14.10节）中提供升级关键字”。
If an unsecured response would be unacceptable, a client MUST send an OPTIONS request first to complete the switch to TLS/1.0 (if possible).
如果不可接受不安全响应，则客户端必须首先发送选项请求以完成到TLS/1.0的切换（如果可能）。
OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
As specified in HTTP/1.1 [1], if the server is prepared to initiate the TLS handshake, it MUST send the intermediate "101 Switching Protocol" and MUST include an Upgrade response header specifying the tokens of the protocol stack it is switching to:
如HTTP/1.1[1]中所述，如果服务器准备启动TLS握手，则必须发送中间“101交换协议”，并且必须包含一个升级响应头，指定其切换到的协议堆栈的令牌：
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
Note that the protocol tokens listed in the Upgrade header of a 101 Switching Protocols response specify an ordered 'bottom-up' stack.
请注意，101交换协议响应的升级标头中列出的协议令牌指定了一个有序的“自底向上”堆栈。
As specified in HTTP/1.1 [1], Section 10.1.2: "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response".
如HTTP/1.1[1]第10.1.2节所述：“服务器将在终止101响应的空行之后立即将协议切换到响应的升级头字段定义的协议”。
Once the TLS handshake completes successfully, the server MUST continue with the response to the original request. Any TLS handshake failure MUST lead to disconnection, per the TLS error alert specification.
一旦TLS握手成功完成，服务器必须继续响应原始请求。根据TLS错误警报规范，任何TLS握手失败都必须导致断开连接。
The Upgrade response header field advertises possible protocol upgrades a server MAY accept. In conjunction with the "426 Upgrade Required" status code, a server can advertise the exact protocol upgrade(s) that a client MUST accept to complete the request.
升级响应标头字段公布服务器可能接受的协议升级。结合“426需要升级”状态代码，服务器可以公布客户端必须接受才能完成请求的确切协议升级。
As specified in HTTP/1.1 [1], the server MAY include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of the protocols listed.
如HTTP/1.1[1]中所述，服务器可在除101或426之外的任何响应中包括升级报头，以指示切换到所列协议的任何（组合）的意愿。
A server MAY indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which MUST include an an Upgrade header field specifying the token of the required TLS version.
服务器可能会使用“426需要升级”状态代码指示没有TLS的客户端请求无法完成，该状态代码必须包括一个指定所需TLS版本令牌的升级头字段。
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
The server SHOULD include a message body in the 426 response which indicates in human readable form the reason for the error and describes any alternative courses which may be available to the user.
服务器应在426响应中包括消息正文，该消息正文以人类可读的形式指示错误的原因并描述可供用户使用的任何替代过程。
Note that even if a client is willing to use TLS, it must use the operations in Section 3 to proceed; the TLS handshake cannot begin immediately after the 426 response.
请注意，即使客户愿意使用TLS，也必须使用第3节中的操作才能继续；TLS握手不能在426响应后立即开始。
As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change.
作为逐跳标头，升级在每对HTTP交易对手之间进行协商。如果用户代理向代理发送带有升级头的请求，则它请求更改自身与代理之间的协议，而不是端到端更改。
Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks, this memo specifies the CONNECT method to establish a tunnel across proxies.
由于TLS尤其需要端到端连接来提供身份验证和防止中间人攻击，因此本备忘录指定了连接方法以跨代理建立隧道。
Once a tunnel is established, any of the operations in Section 3 can be used to establish a TLS connection.
一旦建立了隧道，第3节中的任何操作都可用于建立TLS连接。
If an origin server receives an Upgrade header from a proxy and responds with a 101 Switching Protocols response, it is changing the protocol only on the connection between the proxy and itself. Similarly, a proxy might return a 101 response to its client to change the protocol on that connection independently of the protocols it is using to communicate toward the origin server.
如果源服务器从代理服务器接收到升级头并以101交换协议响应进行响应，则它仅在代理服务器与自身之间的连接上更改协议。类似地，代理可能会向其客户端返回101响应，以更改该连接上的协议，而不依赖于它用于与源服务器通信的协议。
These scenarios also complicate diagnosis of a 426 response. Since Upgrade is a hop-by-hop header, a proxy that does not recognize 426 might remove the accompanying Upgrade header and prevent the client from determining the required protocol switch. If a client receives a 426 status without an accompanying Upgrade header, it will need to request an end to end tunnel connection as described in Section 5.2 and repeat the request in order to obtain the required upgrade information.
这些场景还使426响应的诊断复杂化。由于升级是逐跳标头，因此不识别426的代理可能会删除附带的升级标头，并阻止客户端确定所需的协议交换机。如果客户端接收到426状态，但没有附带的升级标头，则需要按照第5.2节中的说明请求端到端隧道连接，并重复该请求以获得所需的升级信息。
This hop-by-hop definition of Upgrade was a deliberate choice. It allows for incremental deployment on either side of proxies, and for optimized protocols between cascaded proxies without the knowledge of the parties that are not a part of the change.
这种逐跳升级的定义是经过深思熟虑的选择。它允许在代理的任一侧进行增量部署，并允许在级联代理之间进行优化协议，而不需要知道不属于变更一部分的各方。
A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line is always an 'authority' as defined by URI Generic Syntax [2], which is to say the host name and port number destination of the requested connection separated by a colon:
CONNECT方法请求代理代表其建立隧道连接。请求行的请求URI部分始终是URI通用语法[2]定义的“授权”，即请求连接的主机名和端口号目标由冒号分隔：
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, of course, since the tunnel must be established first.
其他HTTP机制通常可以与CONNECT方法一起使用——当然，端到端协议升级请求除外，因为必须首先建立隧道。
For example, proxy authentication might be used to establish the authority to create a tunnel:
例如，代理身份验证可用于建立创建隧道的权限：
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
Like any other pipelined HTTP/1.1 request, data to be tunneled may be sent immediately after the blank line. The usual caveats also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
与任何其他流水线式HTTP／1.1请求一样，要传输的数据可以在空行之后立即发送。通常的警告也适用：如果最终响应为否定，则可能会丢弃数据；如果有多个TCP段未完成，则可能会在没有响应的情况下重置连接。
Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has switched to tunneling the current connection to that server connection.
对连接请求的任何成功（2xx）响应都表示代理已建立到请求的主机和端口的连接，并已切换到通过隧道连接到该服务器连接的当前连接。
It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the first proxy SHOULD make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy MUST NOT respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
可能是代理本身只能通过另一个代理到达请求的源服务器。在这种情况下，第一个代理应该向下一个代理发出连接请求，请求向管理局提供隧道。代理不得使用任何2xx状态代码进行响应，除非它与管理局建立了直接或隧道连接。
An origin server which receives a CONNECT request for itself MAY respond with a 2xx status code to indicate that a connection is established.
接收自身连接请求的源服务器可能会使用2xx状态代码进行响应，以指示已建立连接。
If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that peer undelivered, that data will be discarded.
如果在任何一点，其中一个对等点断开连接，则来自该对等点的任何未完成数据都将传递给另一个对等点，之后，代理将终止另一个连接。如果有未交付给该对等方的未完成数据，则该数据将被丢弃。
Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.
可靠、可互操作的升级功能协商需要明确的故障信号。426升级所需状态代码允许服务器明确说明给定资源必须使用的精确协议扩展。
It might at first appear that the response should have been some form of redirection (a 3xx code), by analogy to an old-style redirection to an https: URI. User agents that do not understand Upgrade: preclude this.
起初，响应可能是某种形式的重定向（3xx代码），类似于对https:URI的旧式重定向。不了解升级的用户代理：排除此情况。
Suppose that a 3xx code had been assigned for "Upgrade Required"; a user agent that did not recognize it would treat it as 300. It would then properly look for a "Location" header in the response and attempt to repeat the request at the URL in that header field. Since it did not know to Upgrade to incorporate the TLS layer, it would at best fail again at the new URL.
假设为“需要升级”分配了3xx代码；如果用户代理不识别它，则会将其视为300。然后，它将在响应中正确地查找“Location”头，并尝试在该头字段中的URL处重复请求。因为它不知道如何升级以合并TLS层，所以在新的URL上它最多只能再次失败。
IANA shall create registries for two name spaces, as described in BCP 26 [10]:
IANA应按照BCP 26[10]中的描述，为两个名称空间创建注册表：
o HTTP Status Codes o HTTP Upgrade Tokens
o HTTP升级令牌的HTTP状态代码
The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response. The initial values for this name space are those specified by:
HTTP状态代码注册表在HTTP响应的状态行中定义状态代码令牌的名称空间。此名称空间的初始值由以下各项指定：
1. Draft Standard for HTTP/1.1 [1] 2. Web Distributed Authoring and Versioning [4] [defines 420-424] 3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425] 4. Section 6 [defines 426]
1. HTTP/1.1[1]2的标准草案。Web分布式创作和版本控制[4][定义420-424]3。WebDAV高级集合[5]（正在进行的工作）[定义425]4。第6节[定义426]
Values to be added to this name space SHOULD be subject to review in the form of a standards track document within the IETF Applications Area. Any such document SHOULD be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 [1].
要添加到此名称空间的值应以IETF应用程序区域内的标准跟踪文档的形式进行审查。任何此类文件应可通过HTTP/1.1[1]标准草案的“过时”或“更新”状态进行追踪。
The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade HTTP header field. Each registered token should be associated with one or a set of specifications, and with contact information.
HTTP升级令牌注册表定义用于在升级HTTP头字段中标识协议的产品令牌的名称空间。每个注册的令牌都应该与一个或一组规范以及联系信息相关联。
The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product':
HTTP/1.1[1]的标准草案规定这些令牌遵守“产品”的生产：
product = token ["/" product-version] product-version = token
产品=令牌[“/”产品版本]产品版本=令牌
Registrations should be allowed on a First Come First Served basis as described in BCP 26 [10]. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules:
如BCP 26[10]所述，注册应以先到先得的方式进行。这些规范无需为IETF文件或接受IESG审查，但应遵守以下规则：
1. A token, once registered, stays registered forever. 2. The registration MUST name a responsible party for the registration. 3. The registration MUST name a point of contact. 4. The registration MAY name the documentation required for the token. 5. The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. 6. The responsible party for the first registration of a "product" token MUST approve later registrations of a "version" token together with that "product" token before they can be registered. 7. If absolutely required, the IESG MAY reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted.
1. 令牌一旦注册，将永远保持注册状态。2.注册必须指定负责注册的一方。3.注册必须指定一个联系人。4.注册可以命名令牌所需的文档。5.责任方可随时更改注册。IANA将保留所有此类变更的记录，并应要求提供这些变更。6.首次注册“产品”令牌的责任方必须批准“版本”令牌以及该“产品”令牌的后续注册，然后才能注册。7.如果绝对需要，IESG可以重新分配代币的责任。这通常仅在无法联系到责任方的情况下使用。
This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol [6].
本规范将协议令牌“TLS/1.0”定义为TLS协议指定的协议的标识符[6]。
It is NOT required that specifications for upgrade tokens be made publicly available, but the contact information for the registration SHOULD be.
不要求公开升级令牌的规范，但应提供注册的联系信息。
The potential for a man-in-the-middle attack (deleting the Upgrade header) remains the same as current, mixed http/https practice:
中间人攻击（删除升级头）的可能性与当前混合http/https做法相同：
o Removing the Upgrade header is similar to rewriting web pages to change https:// links to http:// links. o The risk is only present if the server is willing to vend such information over both a secure and an insecure channel in the first place. o If the client knows for a fact that a server is TLS-compliant, it can insist on it by only sending an Upgrade request with a no-op method like OPTIONS. o Finally, as the https: specification warns, "users should carefully examine the certificate presented by the server to determine if it meets their expectations".
o 删除升级头类似于重写网页以将https://链接更改为http://链接。o只有当服务器愿意首先通过安全通道和不安全通道出售此类信息时，才存在风险。o如果客户机知道某个服务器符合TLS，那么它可以通过只发送带有类似于选项的无操作方法的升级请求来坚持它。o最后，正如https:specification警告的那样，“用户应该仔细检查服务器提供的证书，以确定它是否满足他们的期望”。
Furthermore, for clients that do not explicitly try to invoke TLS, servers can use the Upgrade header in any response other than 101 or 426 to advertise TLS compliance. Since TLS compliance should be considered a feature of the server and not the resource at hand, it should be sufficient to send it once, and let clients cache that fact.
此外，对于不显式尝试调用TLS的客户端，服务器可以在除101或426之外的任何响应中使用升级头来公布TLS遵从性。由于TLS合规性应被视为服务器的一项功能，而不是手头的资源，因此只需发送一次就足够了，并让客户端缓存这一事实。
While nothing in this memo affects the definition of the 'https' URI scheme, widespread adoption of this mechanism for HyperText content could use 'http' to identify both secure and non-secure resources.
虽然本备忘录中的任何内容都不会影响“https”URI方案的定义，但对超文本内容广泛采用这种机制可能会使用“http”来识别安全和非安全资源。
The choice of what security characteristics are required on the connection is left to the client and server. This allows either party to use any information available in making this determination. For example, user agents may rely on user preference settings or information about the security of the network such as 'TLS required on all POST operations not on my local net', or servers may apply resource access rules such as 'the FORM on this page must be served and submitted using TLS'.
连接所需的安全特性由客户端和服务器选择。这使得任何一方都可以使用任何可用信息来做出此决定。例如，用户代理可能依赖于用户偏好设置或有关网络安全性的信息，例如“非本地网络上的所有POST操作都需要TLS”，或者服务器可能应用资源访问规则，例如“必须使用TLS提供和提交此页面上的表单”。
A generic TCP tunnel is fraught with security risks. First, such authorization should be limited to a small number of known ports. The Upgrade: mechanism defined here only requires onward tunneling at port 80. Second, since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. A putative HTTP client CONNECTing to port 25 could relay spam via SMTP, for example.
通用TCP隧道充满安全风险。首先，这种授权应限于少数已知端口。此处定义的升级：机制只需要在端口80处进行向前隧道。其次，由于隧道传输的数据对代理不透明，因此隧道传输到其他已知或保留端口会有额外的风险。例如，连接到端口25的假定HTTP客户端可以通过SMTP转发垃圾邮件。
References
工具书类
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[1] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic Syntax", RFC 2396, August 1998.
[2] Berners Lee，T.，Fielding，R.和L.Masinter，“URI通用语法”，RFC 23961998年8月。
[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[3] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "Web Distributed Authoring and Versioning", RFC 2518, February 1999.
[4] Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.和D.Jensen，“Web分布式创作和版本控制”，RFC25181999年2月。
[5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", Work In Progress.
[5] Slein，J.，Whitehead，E.J.，等，“WebDAV高级收集协议”，正在进行中。
[6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[6] Dierks，T.和C.Allen，“TLS协议”，RFC 2246，1999年1月。
[7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[7] Herriot，R.，Butler，S.，Moore，P.和R.Turner，“互联网打印协议/1.0：编码和传输”，RFC 25651999年4月。
[8] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", Work In Progress. (Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
[8] 罗托宁，A.，“通过Web代理服务器隧道传输基于TCP的协议”，正在进行中。（也可从以下网址获得：Luotonen，Ari.Web代理服务器，Prentice Hall，1997 ISBN:0136806120。）
[9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[9] Rose，M.“使用XML编写I-D和RFC”，RFC 2629，1999年6月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US
Rohit Khare 4K Associates/UC Irvine 3207美国加利福尼亚州帕洛维德Irvine 92612
Phone: +1 626 806 7574
EMail: rohit@4K-associates.com
URI: http://www.4K-associates.com/
Phone: +1 626 806 7574
EMail: rohit@4K-associates.com
URI: http://www.4K-associates.com/
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place Suite 400 Maynard, MA 01754 US
Scott Lawrence Agranat Systems，Inc.美国马萨诸塞州梅纳德市钟塔广场5号400套房01754
Phone: +1 978 461 0888
EMail: lawrence@agranat.com
URI: http://www.agranat.com/
Phone: +1 978 461 0888
EMail: lawrence@agranat.com
URI: http://www.agranat.com/
The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy servers", [8] by Ari Luotonen of Netscape Communications Corporation. It was widely implemented by HTTP proxies, but was never made a part of any IETF Standards Track document. The method name CONNECT was reserved, but not defined in [1].
Netscape Communications Corporation的Ari Lootonen在一份名为“通过Web代理服务器传输基于TCP的协议”的正在进行的工作[8]中对连接方法进行了最初的描述。它由HTTP代理广泛实现，但从未成为任何IETF标准跟踪文档的一部分。方法名CONNECT已保留，但未在[1]中定义。
The definition provided here is derived directly from that earlier memo, with some editorial changes and conformance to the stylistic conventions since established in other HTTP specifications.
这里提供的定义直接来自于之前的备忘录，其中有一些编辑性的更改，并且符合其他HTTP规范中建立的风格惯例。
Additional Thanks to:
额外感谢：
o Paul Hoffman for his work on the STARTTLS command extension for ESMTP. o Roy Fielding for assistance with the rationale behind Upgrade: and its interaction with OPTIONS. o Eric Rescorla for his work on standardizing the existing https: practice to compare with. o Marshall Rose, for the xml2rfc document type description and tools [9]. o Jim Whitehead, for sorting out the current range of available HTTP status codes. o Henrik Frystyk Nielsen, whose work on the Mandatory extension mechanism pointed out a hop-by-hop Upgrade still requires tunneling. o Harald Alvestrand for improvements to the token registration rules.
o Paul Hoffman在ESMTP的STARTTLS命令扩展方面的工作。o Roy Fielding寻求升级背后的基本原理帮助：及其与选项的交互。o Eric Rescorla，感谢他在标准化现有https方面的工作：与之进行比较的实践。o Marshall Rose，用于xml2rfc文档类型描述和工具[9]。o Jim Whitehead，用于整理当前可用HTTP状态代码范围。o Henrik Frystyk Nielsen，他在强制性扩展机制方面的工作指出，逐跳升级仍然需要隧道。o Harald Alvestrand，以改进代币注册规则。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。