RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

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].

关键词 必须MUST、禁止MUST NOT、要求REQUIRED、必须SHALL、禁止SHALL NOT、应当SHOULD、不应当SHOULD NOT、推荐RECOMMENDED、可以MAY 和 可选OPTIONAL 的意义与【RFC2119】一致。

Conformance criteria and considerations regarding error handling are defined in Section 2.5.

关于错误处理的一致性标准以及注意事项会在章节 2.5 中定义。

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B shows the collected grammar with all list operators expanded to standard ABNF notation.

本规范使用了扩展巴科斯范式Augmented Backus-Naur Form（ABNF）标记法【RFC5234】，另外，出于定义的紧凑性的考虑，本规范对 ABNF 规则进行了扩展（见章节 7），允许使用一个 # 操作符（类似于 * 操作符，指代“重复”）来定义一种以逗号分隔的列表。附录 B 展示了所有已收集的包含列表扩展规则以及标准 ABNF 标记的语法。

The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DbbIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character).

本规范引用了以下定义在【RFC5234】附录 B.1 中的核心规则：ALPHA （字母）、CR （回车符）、CRLF （回车换行符）、CTL （控制字符）、DIGIT （十进制数字 0-9）、DQUOTE （双引号）、HEXDIG （十六进制数字 0-9/A-F/a-f）、HTAB （水平制表符）、LF （换行符）、OCTET （八位组字节）、SP （空白）以及 VCHAR （【USASCII】可见字符）。

译注：除非特别说明，本译文所述的“字节”皆为 Octet，而不是 Byte。

As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.

按照惯例，名称以 "obs-" 开头的 ABNF 规则代表这是已经废弃obsolete了的语法，之所以这种规则会出现是为了描述历史遗留的问题。

HTTP is a stateless request/response protocol that operates by exchanging messages (Section 3) across a reliable transport- or session-layer "connection" (Section 6). An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.

HTTP 是一种无状态的请求/响应协议，通过一个可靠的传输层或会话层“连接”来交换消息exchanging messages（章节 3）。HTTP 客户端client是一种用于与服务器建立连接connection（章节 6），向其发送一种或多个 HTTP 请求的应用程序。HTTP 服务器server是一种接受客户端连接，接收 HTTP 请求，发送 HTTP 响应的应用程序。

译注：response 译作“响应”、“应答”，本文统一译为“响应”，作动词时有时会译为“回应…的响应”；message 译作“消息”、“报文”，这里统一译为“消息”。

The terms "client" and "server" refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others. The term "user agent" refers to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps. The term "origin server" refers to the program that can originate authoritative responses for a given target resource. The terms "sender" and "recipient" refer to any implementation that sends or receives a given message, respectively.

术语“客户端”和“服务器”特指在一个具体连接connection中的相关程序所充当的角色。同一个程序可能在某些连接中充当一个客户端，而在其他连接中充当的是一个服务器。术语“用户代理user agent”指的是任何发起请求的各种客户端程序，包括（但不限于）浏览器、爬虫（基于网络的机器人）、命令行工具、定制应用和移动应用。术语“源服务器origin server”指的是任何为一个给定目标资源创建权威响应authoritative response（章节 9.1）的程序。术语“发送端sender”和“接收端recipient”分别指的是任何发送或者接收一个给定消息的实现implementation。

HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate the target resource (Section 5.1) and relationships between resources. Messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see Appendix-A of [RFC7231] for the differences between HTTP and MIME messages).

HTTP 依靠“统一资源标识符Uniform Resource Identifier（URI）标准【RFC3986】”来标识目标资源（章节 5.1）以及资源与资源之间的关系。消息通过类似于互联网邮件【RFC5233】和多用途互联网邮件扩展Multipurpose Internet Mail Extensions（MIME）【RFC2045】的格式来进行传输。对于 HTTP 与 MIME 之间的区别可以查看【RFC7231】附录 A。）

Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (=) between the user agent (UA) and the origin server (O).

大多数 HTTP 的通讯是由 GET 请求组成的，通过向一个 URI 发起检索请求retrieval request（GET）来获得该 URI 所标识的资源一种表示方式representation。在最简单的情况下，可以经由一个在用户代理（UA）和源服务器（O）之间的双向连接bidirectional connection（=）就能完成。

     request   >
UA ======================================= O
                            <   response

A client sends an HTTP request to a server in the form of a request message, beginning with a request-line that includes a method, URI, and protocol version (Section 3.1.1), followed by header fields containing request modifiers, client information, and representation metadata (Section 3.2), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, Section 3.3).

客户端以请求消息request message的形式向服务器发送一个 HTTP 请求。请求消息以一个包含了方法method、URI 和协议版本protocol version的请求行request line（章节 3.1.1）作为开始；随后是包含了请求修饰符request modifiers、客户端信息以及表示形式元数据representation metadata的头字段header fields（章节 3.2）；接着是一个空行，来表示消息头部header section结束；最后是一个包含有效载荷payload body（如果有的话）的消息体message body（章节 3.3）。

译注："header fields" 通常译作头字段、首部字段、报头域等，本文统一译作“头字段”。"message body" 通常译作消息体、消息主体、报文正文等，本文统一译作“消息体”。

A server responds to a client's request by sending one or more HTTP response messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (Section 3.1.2), possibly followed by header fields containing server information, resource metadata, and representation metadata (Section 3.2), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, Section 3.3).

服务器通过发送一个或多个 HTTP 响应消息response message来响应客户端的请求。每个响应消息以一个包含协议版本protocol version、一个成功或失败的状态码status code以及一个描述状态码的文本短语reason phrase来构成的状态行status line（章节 3.1.2）作为开始；随后可能是包含服务器信息、资源元数据以及表示形式元数据representation metadata的头字段header fields（章节 3.2）；接着是一个空行，来表示消息头部header section结束；最后是一个包含有效载荷payload body（如果有的话）的消息体message body（章节 3.3）。

A connection might be used for multiple request/response exchanges, as defined in Section 6.3.

一个连接可能被用于多次请求/响应的消息交换，其定义见章节 6.3。

The following example illustrates a typical message exchange for a GET request (Section 4.3.1 of [RFC7231]) on the URI "http://www.example.com/hello.txt":

下面举例说明对于 URI 为 "http://www.example.com/hello.txt" 的一个典型的 GET 请求（【RFC7231】章节 4.3.1）的消息交换过程。

Client request:

客户端请求：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

Server response:

服务器响应：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video-delivery platforms.

在考虑 HTTP 协议的设计时，很容易会陷入一个误区：认为所有的用户代理都是通用的网页浏览器；所有的源服务器都是大型公共站点。然而实际上并不是这么一回事。一般的 HTTP 用户代理包含了家用电器、音响器材、磅秤、固件升级脚本、命令行程序、移动应用以及各种形状和尺寸的通信设备。同样，一般的 HTTP 源服务器包含家庭自动化单元、可配置的网络组件、办公设备、自主学习的机器人、新闻源、交通摄像头、广告选择器以及视频分发平台。

The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of a request. In many cases, a user agent is installed or configured to run in the background and save its results for later inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.

术语“用户代理user agent”并不是意味着在请求的时候有一个人类用户与软件代理进行直接交互。在许多情况下，用户代理是被安装或配置用于后台运行，并保存其运行结果用于后续检验（或者只保存那些感兴趣的，或者错误的那部分）。例如，爬虫，其典型应用是给定一个起始 URI，然后配置其抓取网页文本的后续行为。

The implementation diversity of HTTP means that not all user agents can make interactive suggestions to their user or provide adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption of normal processing if the user has already made that choice.

HTTP 实现implementations上的差异性，表现为不是所有的用户代理都能为用户提供交互性的建议或者对其关注的安全或隐私提供足够的警示。例如，本规范规定了在某些情况下要求向用户报告错误，但在某些实现implementations上，这些报告信息可能只输出到错误控制台或者日志文件里，这也是允许的。同样，用户可以在用户代理里（例如在高级选项、运行时选项或者不安全操作中）预先配置接下来的默认行为，规范要求当遇到这些默认行为时需要用户确认，而这个确认并不意味着出现一个特定的用户界面或者正常流程被打断，如果用户已经预先做出了选择的话。

HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.

HTTP 能使用中间人intermediaries来满足在通信链路里中转请求的需要。HTTP 有三种中间人：代理proxy、网关gateway和隧道tunnel。在某些情况下，一个中间人可以依据当前接收到的请求来决定是以源服务器、代理、网关还是隧道的方式来处理这个请求。

     >             >             >             >
UA =========== A =========== B =========== C =========== O
           <             <             <             <

The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply only to the connection with the nearest, non-tunnel neighbor, only to the endpoints of the chain, or to all connections along the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request. Likewise, later requests might be sent through a different path of connections, often based on dynamic configuration for load balancing.

上图演示了在用户代理（UA）和源服务器（O）之间的三个中间人（A、B 和 C）。一个请求消息或者响应消息通过依次建立四个单独的连接来穿越整条链路。HTTP 的某些通信选项可能仅适用于通信链路上的某些节点上，例如离其最近的非隧道节点、链路的端点，或者适用于链路上的所有节点。虽然上图以线性的方式展示这条链路（但并不一定是线性的），每个节点都可能在处理多个并行的通信。例如，B 在处理来自 A 的请求的同时，还可能接收到来自 A 之外的多个客户端的请求，并（或）将其转发这些请求到 C 之外的服务器。同样，后面接收到的请求可能被节点依据其负载均衡的策略发送至另外一个不同通信路径上（译注：例如，来自 A 的请求被 B 转发到 D，而不是上图所示的 C）。

译注： 可以将通信链路想像为一条公交线路 A – B – C … X – Y – Z，线路两个端点（起始端/终点站）分别为 A 与 Z，之间的所有站点可以认为是中间人。公交车（请求消息）先从 A 站（用户代理）开始发起，途经 B、C……最终到达 Z 终点站（源服务器），然后公交车（响应消息）以 Z 站作为起点，途经 Y、X……最终返回到终点站 A。

其中“A 到 B”、“B 到 C”等，称之为“逐跳（"hop-by-hop"）”；而“A 到 Z”、“Z 到 A”，称之为“端到端”（"end-to-end"）。

The terms "upstream" and "downstream" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream. The terms "inbound" and "outbound" are used to describe directional requirements in relation to the request route: "inbound" means toward the origin server and "outbound" means toward the user agent.

术语“上游upstream”和“下游downstream”用于描述消息流的方向：所有的消息都从上游流到下游。术语“入站inbound”和“出站outbound”用于描述请求的路由方向：“入站”意为数据流朝向源服务器流动，而“出站”意为数据流朝向用户代理流动。

译注：上游与下游，拿刚才公交车的例子，在公交车上行时（从 A 到往 Z）：A 是 B、C、……Z 的上游；B 是 A 的下游，是 C……Z 的上游。在公交车下行时（从 Z 到往 A）刚好相反，Z 是 Y、X、……A 的上游。只要记住，是按公交车（水）的行驶（流动）方向来区分上下游的，它总是从上游开往（流行）下游。

译注：入站与出站，路由器是连接互联网的枢纽，数据流入互联网，这叫“入站”，例如文件上传；流出互联网，这叫“出站”，例如文件下载。

A "proxy" is a message-forwarding agent that is selected by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary for the sake of security, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or payloads while they are being forwarded, as described in Section 5.7.2.

代理proxy，是一种由客户端选定的负责消息转发的中介，一般通过本地设置的规则来接收绝对 URIabsolute URI类型的请求并试图经由 HTTP 接口的翻译translation来满足这些请求。某些翻译是以最低限度来进行的，例如对 "http" URI 进行请求代理；与之相反的是，某些请求可能要求翻译为或翻译自translation to and from完全不同的应用层协议。为了安全性、服务标识或者共享缓存，某些代理一般通过一个共同的中间人，对同一组织的 HTTP 请求进行分组。某些代理被设计为对选定的消息或有效载荷在其被转发时进行转换（见 5.7.2）。

译注：Wikipedia 上对绝对 URI 的描述

A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance through "accelerator" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.

网关gateway（又称为“反向代理reverse proxy”），对于出站通信outbound connection来说网关充当一个源服务器，它会将接收到的请求进行翻译translate，然后转发到站内inbound的一个或多个服务器上。网关通常用于封装遗留或者不受信任的信息服务，通过“加速器”缓存，以及在多机中开启分片或负载均衡来提升 HTTP 服务器的性能。

All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform to user agent requirements on the gateway's inbound connection.

HTTP 中所有对于源服务器的要求都适用于网关的出站通信outbound communication。一个网关可以使用其喜欢的协议与入站网关通信，包括对 HTTP 的私有扩展（已经超出了本标准的范畴）。但是，如果一个 HTTP-to-HTTP 的网关在入站inbound时想跟第三方 HTTP 服务器交互的话应该遵循本标准对于用户代理的要求。

A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as when Transport Layer Security (TLS, [RFC5246]) is used to establish confidential communication through a shared firewall proxy.

隧道tunnel在两个连接之间充当一个盲中继blind relay，即隧道并不会对消息进行更改。隧道在激活后，由 HTTP 请求来进行初始化，但隧道并不作为 HTTP 通信的一部分。在隧道两端的连接都关闭后，隧道将不复存在。经由一个中间人的中转，隧道能够用来扩展一种虚连接（virtual connection），例如传输层安全协议（TLS，[RFC5246]）可以经由一个共享的防火墙代理来建立保密通信confidential communication。

译注："blind relay"，盲中继，只是将字节从一个连接转发到另一个连接中去，不对 Connection 头字段进行特殊的处理。

The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from a man-in-the-middle attack, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.

上述这些类型的中间人仅认为是在 HTTP 通信中作为参与者。这些中间人同样能工作在网络协议栈的底层，过滤或重定向 HTTP 流而不必了解消息发送者的权限或逻辑。网络中间人并不能（在协议层面上）识别出消息是否来自于中间人攻击（man-in-the-middle attack），因此，有时会因为中间人的实现implementations有误没有遵循 HTTP 语义从而引入了安全隐患或者互操作性问题。

For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919] or "captive portal") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.

例如，一个拦截代理interception proxy（一般又叫作透明代理transparent proxy，【RFC1919】或者捕获门户（强制网络门户）captive portal）与一个 HTTP 代理的区别在于它不是由客户端选择的，但是，拦截代理会过滤或者重定向 TCP 80 出口端口的数据包（有时还包括其他一般端口的流量）。拦截代理在公有网络访问点²里很常见，作为一种在允许使用非本地互联网服务之前的强制认证手段；同样也常见于企业防火墙里，用于强制执行网络使用上的策略。

译注：强制网络门户，是一个在用户使用无线网络前，先被导向至的 Web 网页，它是使用公共访问网络的用户在被授予访问权限前必须访问和交互的页面。

HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems.

HTTP 被定义为一种无状态的协议，意味着每一个请求消息都能够（在不需要依赖其他消息的情况下）被单独理解。许多实现implementations依托于 HTTP 无状态性来复用代理过的连接或者通过多台服务器实施对请求的动态负载均衡。因此，一个服务器 禁止 假设同一个连接里的两个请求是来自于同一个用户代理，除非是连接是安全的或者这些请求是该用户代理特有的。目前已发现某些非标准的 HTTP 扩展（例如【RFC4559】）违反了这一要求，结果就是引发安全性和互操作性的问题。

译注：源服务器或中间人能够完全理解每一个请求消息的含义，这种理解并不用基于该请求消息的前一个或多个请求消息的内容。

A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.

缓存cache，是一种保存之前的响应消息的本地存储，以及控制其内的消息的存储、获取和删除的子系统。缓存存储了可缓存的cacheable响应是为了减少将来的响应时间和网络带宽消耗。任何客户端或者服务器 可以 使用缓存，但是，当服务器作为隧道tunnel而使用时，不能使用缓存。

The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request that has not been cached by UA or A.

缓存cache的作用是缩短请求/响应链，体现为在一个有缓存参与的请求/响应链中，如果链路中的某个缓存cache保存并返回了与该请求相匹配的响应消息。下图的请求响应链的意思是，如果 B 保存了之前从源服务器 O （经过 C）返回的响应消息的副本，而这个响应没有缓存于用户代理 UA 或者 A 中，那么 B 就可以直接返回缓存的响应，而不用再转发至 C。

     >             >
UA =========== A =========== B - - - - - - C - - - - - - O
           <             <

A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in Section 2 of [RFC7234].

如果一个缓存被允许去存储一个响应消息的副本用于应答随后的请求，那么这个响应消息是“可缓存的cacheable”。即使一个响应是可缓存的，也可能存在一些来自客户端或源服务器的额外约束来规定在什么情况下所缓存的响应消息能够用于具体的请求。HTTP 关于缓存的行为cache behavior以及可缓存的响应cacheable reponses的定义，见【RFC7234】第二章。

There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations. These include national hierarchies of proxy caches to save transoceanic bandwidth, collaborative systems that broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on.

缓存cache的各种各样的架构和配置广泛存在于万维网和大型组织中，包括用于节省越洋带宽的国际级的代理缓存，广播或组播缓存项的协作系统，用于离线或高延迟环境的预取的缓存档案等等。

This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.

本规范旨在为参与 HTTP 通信的角色制定一致性准则。因此，HTTP 对一致性的要求着眼于发送端、接收端、客户端、服务端、用户代理、中间人、源服务器、代理、网关和缓存，取决于哪些行为被要求所约束。附加的要求着眼于实现implementations、资源所有者以及应用于超出单一通信时的协议元素登记条目protocol element registrations。

译注：本文多处提及“协议元素”这一术语，它指代组成一个完整协议的某个部分。为了方便描述一个协议的组成，我们会对协议的各个组成部分进行命名，这个经过命名的组成部分就是一个协议元素。例如，URI 由 scheme、authority、path、query、fragment 等元素组合而成。更多详情见【RFC6365】章节 6。

The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.

动词“生成generate”和“发送send”，用于区分“创建一个协议元素”和“仅仅将其接收到的元素转发到下游”。

An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP.

判断一个实现implementation是否符合本规范，需要判断它是否遵循了本规范中涉及到对参与 HTTP 通信的所有角色的所有要求。

Conformance includes both the syntax and semantics of protocol elements. A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false. A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message).

一致性包含协议元素protocol elements的句法syntax及语义semantics。发送端 禁止 生成其明知是不正确的协议元素。发送端 禁止 生成与相关 ABNF 规则所定义的语法grammar不相匹配的协议元素。在给定的消息中，发送端 禁止 生成只允许在其他角色参与者（也就是说，一种发送端所不具备的角色）中生成的协议元素或相关句法替代品。

译注：不能将错就错。

译注：编译原理或语言学中的 "grammar", "semantics" 以及 "syntax" 这几个概念了解一下？

When a received protocol element is parsed, the recipient MUST be able to parse any value of reasonable length that is applicable to the recipient's role and that matches the grammar defined by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then forward the header field without further parsing inside the field-value.

当一个接收到的协议元素被解析parse时，接收端必须能够解释任何适用于接收端这一角色以及与相关 ABNF 规则所定义的语法相匹配的、合理长度的值。需要注意的是，某些接收到的协议元素可能不被解析parse。例如，一个中间人在转发消息时可能会将一个头字段header-field解析为头字段名field-name和字段值field-value，但转发头字段时并没有再对字段值进一步解析parse。

译注：出于兼容性考虑，当接收者的 HTTP 版本是 HTTP/1.0，假如接到到的消息版本是 HTTP/1.1，那么某些头字段可能会被忽略。

HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two decades of HTTP use and is expected to continue changing in the future.

HTTP 并没有对其协议元素作具体长度限制，因为“多少的长度才算合适”这个问题过于宽泛，需要依据实现implementations具体的部署场景deployment context和目的来决定。因此，发送端和接收端之间的互操作性interoperability取决于它们“对于每一个协议元素，如何才算是合理长度”的共同期望。此外，对于某些协议元素来说，多少才算是一个通俗合理的长度这个问题的答案已经在过去二十多年来完全变更了，而且在将来仍会继续变更。

At a minimum, a recipient MUST be able to parse and process protocol element lengths that are at least as long as the values that it generates for those same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a request target.

接收端必须能够最低限度地解析parse和处理process协议元素的长度，至少和它在其他消息中生成的同样一个协议元素的长度一致。例如，一个源服务器公布了一个非常长的 URI 来引用其自身资源，当它接收到以这个 URI 作为目标资源的请求时， 源服务器必须能够正确地解析和处理这个 URI。

A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings.

接收端 必须 依据本规范（及其后续扩展）所定义的语义来解释interpret其接收到的协议元素，除非接收端已经（通过经验或者配置）确定发送端并没有正确实现那些语义。例如，源服务器接到一个请求消息，这个请求的 Accept-Encoding 消息头字段表明发送端支持某些编码类型，源服务器通过检查这个请求的 User-Agent 头字段来获得这个用户代理的实现版本，（从过往的经验上）得知实际上这个用户代理并不能正确处理其声明的编码类型，于是源服务器可以忽略接收到的 Accept-Encoding 消息头字段的内容。

Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.

除非另有说明，接收端 可以 尝试从一个不合法的消息结构中恢复recover出一个可用的协议元素。HTTP 协议在不用的应用场景上会有不同的错误处理策略的要求，因此，协议本身并没有定义具体的错误处理机制，除非这种错误直接影响到安全性。例如，一个网页浏览器接收到一个响应消息，响应消息的 Location 头字段依据 ABNF 规则并不能合法解析parse到，于是浏览器可能希望进行透明恢复（transparently recover）；但是对于一个系统控制客户端，可能认为任何方式的错误恢复都是危险的。

译注：这里是拿“Web Browser”与所谓的“Systems Control Client”作对比。

HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.

HTTP 使用“<主版本>.<次版本>”这种编号方案numbering scheme来表明协议的版本。本规范定义了版本号“1.1”。整体来说，协议版本表明了发送端遵循了哪一个版本的 HTTP 规范。

译注：这里出现了本规范提及过的两种类型的 scheme 之一：numbering scheme，也就是编号方案。另外一种 scheme 是 URI scheme，URI 方案，也就是我们常见的 "http" 和 "https"。

The version of an HTTP message is indicated by an HTTP-version field in the first line of the message. HTTP-version is case-sensitive.

HTTP 协议的版本通过在消息的第一行的 HTTP-version 字段来指定。需要注意的是，HTTP-version 是区分大小写的，以下是 HTTP-version 的 ABNF 规则。

HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive 

The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version within that major version to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).

HTTP 的版本号由 2 个十进制数组成，中间以英文句号 "." 分隔。第一个数字（主版本号major version）表示 HTTP 消息的句法，第二个数字（次版本号minor version）表示发送端在接下来的通信中将会遵循以及能够理解的最高次版本。次要版本号声明了发送端的通信能力，即使发送端仅仅使用协议的向后兼容backwards-compatible的子集，因此让接收端了解更多高级功能能够被用于响应（作为服务器）或者用于接下来的请求（作为客户端）。

When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt of a message, that the recipient supports HTTP/1.1.

当一个 HTTP/1.1 消息被发送到一个 HTTP/1.0 接收端【RFC1945】或者一个接收端的版本号未知，HTTP/1.1 消息会被构建成一个能够被解释interprete为一个合法的 HTTP/1.0 消息，如果忽略掉所有在 HTTP/1.1 新增的功能的话。本规范明确了接收端使用新功能的版本要求，以便于发送端可以仅仅使用兼容性功能与接收端通信，直到发送端（通过配置，或者接收到的消息）已经明确接收端支持 HTTP/1.1。

译注：也就是说，HTTP/1.1 是向后兼容的。

译注：发送端如何得知接收端支持 HTTP/1.1？一个办法是，发送端不管接收端是否支持，强制使用 HTTP/1.1；另一个办法是解析从接收端响应的消息，分析其是否真正实现了 HTTP/1.1。

The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.

在规范中，在主版本major version一致的情况下，不同次版本minor version并不会对消息头字段有不同的解释interpretation，虽然接收者在缺少这些字段时的默认行为会有所不同。除非具体说明，定义在 HTTP/1.1 版本的头字段同样适用于所有 HTTP/1.x 版本。特别是，Host 和 Connection 头字段应该为所有 HTTP/1.x 版本所实现，无论它们声明是否与 HTTP/1.1 版本一致。

New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. Header field extensibility is discussed in Section 3.2.1.

将来新的头字段能够在不改变当前协议版本的情况下被引入，如果定义这些新头字段的语义允许它们能够在接收者无法识别的情况下被其安全忽略safely ignored。头字段的扩展性extensibility会在 章节 3.2.1 中讨论。

Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages. In other words, they are not allowed to blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version to determine what features are safe to use for later communication with that sender.

处理 HTTP 消息的中间人（除了作为隧道tunnel的中间人） 必须 在其转发消息中包含它们自身的 HTTP-version。换句话说，在以上中间人接收和发送消息的时候，它们并不允许在没有确保消息的版本与自身所使用的 HTTP 版本是否一致的情况下盲转发blindly forward HTTP 消息的首行。当下游downstream接收端使用消息的发送端版本来决定“对于接下来与之通信，什么功能能够安全使用”时，在没有重写 HTTP-version 的情况下直接转发一个 HTTP 消息可能会导致通信错误。

译注：隧道作为盲中介，它并不会对消息本身作修改。

A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known. A client MUST NOT send a version to which it is not conformant.

客户端所发送的请求消息版本 应当 等于其支持的最高版本，同时，客户端的主版本major version不能高于服务器支持的最高主版本号（如果客户端知道服务器的主版本号的话）。客户端 禁止 发送自身不支持的协议版本。

译注：不能打肿脸充胖子。例如，当客户端最高仅支持 HTTP/1.0 时，请求行的 HTTP-version 字段不能是 HTTP/1.1。

A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions.

如果客户端知道服务器没有正确实现 HTTP 规范，客户端 可以 向服务器发送较低版本的请求，但仅当客户端在至少发送一次正常（最高版本）请求未遂，并且依据服务器的响应消息里的状态码或者头字段断定服务器不能正确处理更高版本的请求的情况下才允许上述做法。

A server SHOULD send a response version equal to the highest version to which the server is conformant that has a major version less than or equal to the one received in the request. A server MUST NOT send a version to which it is not conformant. A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version.

服务器所发送的响应消息版本 应当 低于或等于其接收到的请求消息的主版本major version。服务器 不能 发送自身不支持的协议版本。如有必要，当服务器不支持客户端所声明的 HTTP 协议主版本时，服务器可以发送一个 505 (HTTP Version Not Supported) 响应来拒绝来自客户端的请求服务。

A server MAY send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor version of the protocol. Such protocol downgrades SHOULD NOT be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., User-Agent) uniquely match the values sent by a client known to be in error.

如果服务器知道或者怀疑客户端没有正确实现 HTTP 规范而且不能够正确处理更高版本的响应的时候，服务器 可以 发送 HTTP/1.0 响应。例如，当客户端没有正确解析parse协议版本号，或者已知一个中间人即使自身没有实现给定的 HTTP-version 的次版本的规范（即不支持给定版本的 HTTP 协议）仍然盲转发该 HTTP-version 等。不应该 执行上述这种协议版本的降级行为，除非服务器（或其他中间人）被特定客户端的特性所触发，例如当唯一匹配到客户端所发送的一个或多个请求头字段（例如 User-Agent）是已知会导致错误。

The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented for the changes introduced between [RFC2068] and [RFC2616], and this revision has specifically avoided any such changes to the protocol.

HTTP 版本编号的设计意图是：主版本号major number只会在引入不兼容的消息句法的情况下才会增加；次版本号minor number只会在对协议的改动会引起语义的添加，或者赋予发送端新的能力时才会增加。但是，从【RFC2068】到【RFC2616】的修订过程中，次版本号并没有增加（仍然是 HTTP/1.1），同时，本次修订已经明确避免对协议（版本号）的变动。

When an HTTP message is received with a major version number that the recipient implements, but a higher minor version number than what the recipient implements, the recipient SHOULD process the message as if it were in the highest minor version within that major version to which the recipient is conformant. A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version.

接收端接收到一个 HTTP 消息，如果接收端兼容该消息的主版本号，但不兼容其次版本号（接收端所支持的次版本号低于该消息所标识的次版本号），那么，接收端 应当 以其所能支持的最高次版本（前题是相同主版本）的方式来处理这个消息。当接收端接收到一个消息，如果该消息的次要版本号高于接收端所实现的，接收端可以假设这个消息能够向后兼容所有具有相同主版本号的实现implementation，让其被安全处理。

Uniform Resource Identifiers (URIs) [RFC3986] are used throughout HTTP as the means for identifying resources (Section 2 of [RFC7231]). URI references are used to target requests, indicate redirects, and define relationships.

统一资源标识符（URIs）【RFC3986】 作为标识资源（【RFC7231】章节 2）的手段，广泛使用于 HTTP 中。URI 引用URI references用于定位请求，标识重定向以及定义关联。

The definitions of "URI-reference", "absolute-URI", "relative-part", "scheme", "authority", "port", "host", "path-abempty", "segment", "query", and "fragment" are adopted from the URI generic syntax. An "absolute-path" rule is defined for protocol elements that can contain a non-empty path component. (This rule differs slightly from the path-abempty rule of RFC 3986, which allows for an empty path to be used in references, and path-absolute rule, which does not allow paths that begin with "//".) A "partial-URI" rule is defined for protocol elements that can contain a relative URI but not a fragment component.

URI-reference，absolute-URI，relative-part，scheme，authority，port，host，path-abempty，segment，query 和 fragment 是引用自【RFC3986】。absolute-path 规则用于定义能够包含一个非空路径的协议元素（这个规则在 RFC3986 中与 path-abempty 有些微的区别：path-abempty 允许在引用中使用空路径，而 path-absolute 规则不允许以 "//" 开头）。partial-URL 规则用于定义能包含一个相对 URI 但不能包含一个 fragment 的协议元素。

URI-reference = <URI-reference, see [RFC3986], Section 4.1>
absolute-URI  = <absolute-URI, see [RFC3986], Section 4.3>
relative-part = <relative-part, see [RFC3986], Section 4.2>
scheme        = <scheme, see [RFC3986], Section 3.1>
authority     = <authority, see [RFC3986], Section 3.2>
uri-host      = <host, see [RFC3986], Section 3.2.2>
port          = <port, see [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, see [RFC3986], Section 3.3>
segment       = <segment, see [RFC3986], Section 3.3>
query         = <query, see [RFC3986], Section 3.4>
fragment      = <fragment, see [RFC3986], Section 3.5>

absolute-path = 1*( "/" segment )
partial-URI   = relative-part [ "?" query ]

译注：【RFC3986】章节 3 有 URI 的完整图解，如下图所示：

  foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |           |            |            |        |
scheme     authority       path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request URI (Section 5.5).

HTTP 中的每一个允许 URI 引用的协议元素都会在它的 ABNF 产生中提及到这个元素允许哪种形式的引用：

1. 任何形式的引用（URI-reference）
2. 只能是绝对形式的引用（absolute-URI）
3. 只能是路径（path）和可选的查询（query）组成部分
4. 以上一个或多个组合

除非另有说明，URI 引用会解析（parse）为相关的“实际请求 URIeffective request URI”（章节 5.5）。

An HTTP message can be either a request from client to server or a response from server to client. Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (Section 3.3).

一个 HTTP 消息要么是一个从客户端到服务器的请求消息，要么是一个从服务器到客户端的响应消息。从句法上看，这两种类型的消息的区别有两点：

1. 起始行start line：请求消息的起始行称为请求行request line，响应消息的起始行称为状态行status line
2. 测算消息体的长度的算法（章节 3.3）

In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats, but, in practice, servers are implemented to only expect a request (a response is interpreted as an unknown or invalid request method) and clients are implemented to only expect a response.

理论上，客户端同样能够接收请求消息，服务器同样能够接收响应消息，只需要让它们区别好消息起始行的不同格式就可以了。但实际上，一般将服务端实现为仅预期接收请求（而接收到响应的话，服务器会将其解释interpret为一个未知或非法的请求方法），将客户端实现为仅预期接收响应。

start-line     = request-line / status-line

Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace.

每一个头字段header field都由一个字段名field name及随后的一个分号（":"）、可选的前置空白、一个字段值field value、一个可选的结尾空白组成。

header-field   = field-name ":" OWS field-value OWS

field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text

obs-fold       = CRLF 1*( SP / HTAB )
               ; obsolete line folding
               ; see Section 3.2.4

The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, the Date header field is defined in Section 7.1.1.2 of [RFC7231] as containing the origination timestamp for the message in which it appears.

头字段名称 field-name 将其对应的头字段值 field-value 算作这个消息带有相应头字段的语义。例如，定义在【RFC7231】章节 7.1.1.2 的 Date 头字段的出现表明包含了这个消息诞生的时间戳。

The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body is identical to the payload body unless a transfer coding has been applied, as described in Section 3.3.1.

HTTP 消息的消息体（如果存在的话）是用来运载请求或响应的有效载荷payload body的。除非应用了传输编码，消息体message body等价于有效载荷payload body，详情见章节 3.3.1。

message-body = *OCTET

The rules for when a message body is allowed in a message differ for requests and responses.

在什么情况下才允许带有消息体，有相应的规则进行约束，而且对于请求消息和响应消息的规则是不尽相同的。

The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. Request message framing is independent of method semantics, even if the method does not define any use for a message body.

在一个请求中是否会出现消息体，以消息头中是否带有 Content-Length 或者 Transfer-Encoding 头字段作为信号。请求消息的分帧是独立于请求方法request method的语义之外的，即使请求方法并没有任何用于一个消息体的相关定义。

The presence of a message body in a response depends on both the request method to which it is responding and the response status code (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 of [RFC7231]) never include a message body because the associated response header fields (e.g., Transfer-Encoding, Content-Length, etc.), if present, indicate only what their values would have been if the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx (Successful) responses to a CONNECT request method (Section 4.3.6 of [RFC7231]) switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length.

在一个响应中是否会出现消息体，取决于请求方法所对应的响应是什么，且响应状态码是什么（章节 3.1.2）。响应给请求方法 HEAD（【RFC7231】章节 4.3.2）的消息永远不会包含一个消息体，这是因为如果出现上述相关的响应头字段（例如，Transfer-Encoding、Content-Length 等），表明仅当这个消息的请求方法被改变为 GET（【RFC7231】章节 4.3.1）的时候，这些头字段才有效⁶。2xx (Successful) 响应给一个请求方法 CONNECT（【RFC7231】章节 4.3.6）。所有 1xx (Informational)、204 (No Content) 和 304 (Not Modified) 的响应消息并不会包含一个消息体。除上述情况以外，所有其他响应消息都会包含一个消息体，虽然消息体的长度可能为零。

A server that receives an incomplete request message, usually due to a canceled request or a triggered timeout exception, MAY send an error response prior to closing the connection.

服务器接收到一个不完整的请求消息，通常是因为这是一个已取消的请求，或者一个触发超时的异常，可以 在关闭连接前发送一个错误响应。

A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding a supposedly chunked transfer coding fails, MUST record the message as incomplete. Cache requirements for incomplete responses are defined in Section 3 of [RFC7234].

当一个连接被过早地关闭或者当一个推想的分块传输代码（chunked transfer coding）解码失败时会导致客户端接收到一个不完整的响应消息，这时候客户端 必须 记录下这个消息是不完整的。缓存cache对于不完整消息的要求定义在【RFC7234】章节 3 里。

If a response terminates in the middle of the header section (before the empty line is received) and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next.

假如一个响应终止在消息头部header section之间（在接收到空行之前），并且状态码可能需要依赖头字段才能传达响应消息的完整意义，那么客户端不能够假设这个“意义”已经传达了；客户端可能需要重复这一次请求，以便于决定下一步将如何行动。

A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection and, thus, is considered complete regardless of the number of message body octets received, provided that the header section was received intact.

一个使用分块传输代码的消息体，如果终止编码的 zero-sized 分块没有被接收到，那么这个消息体是不完整的。一个使用一个合法 Content-Length 的消息，如果所接收到的消息体的大小（按字节来算）小于给定 Content-Length 的大小，那么这个消息是不完整的。一个既没有使用分块传输代码，也没有提供 Content-Length 的响应消息，如果因为连接被关闭而终止，只要该消息所提供的消息头部已经接收完整，那么可以认为消息是完整的，无论消息体的内容被接收到多少。

Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then the user agent MUST count the terminating CRLF octets as part of the message body length.

在 HTTP/1.0 时代，早期的服务器应用可能不能正确读取那些没有以换行符 line-ending 作为结尾的消息体内容。因此，早期的 HTTP/1.0 版本的用户代理可能会在 POST 请求消息中发送一个额外的回车换行 CRLF 来作为一个变通方案。到了 HTTP/1.1，用户代理 不能 在一个请求消息首或尾再添加额外的回车换行 CRLF 了。如果要求以换行符 line-ending 作为请求消息体的结束，那么用户代理 必须 对 CRLF 的字节数目进行计数，包含在消息体的长度之内。

In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line.

出于健壮性的考虑，服务器在等待接收和解析parse一个请求行 request-line 的时候，应当 忽略至少一个空行（CRLF）。

Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.

虽然对于起始行 start-line 和消息头字段header fields的行终结符line terminator是 CRLF 字符序列，但接收端 可以 单独将一个 LF 作为一行的终结，同时忽略 LF 之前的所有 CR。

Although the request-line and status-line grammar rules require that each of the component elements be separated by a single SP octet, recipients MAY instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in security vulnerabilities if there are multiple recipients of the message and each has its own unique interpretation of robustness (see Section 9.5).

虽然请求行request line和状态行status line的语法规则要求每一个组件元素需要以一个空白（8位字节） SP 分隔，但是接收端 可以 改由使用除 CRLF 结束符以外的更宽泛的空白限定符whitespace-delimited word替代 SP 来进行解析，从而将任何形式的空白作为 SP 分隔符来对待，在忽略前置或后置空白的时候。空白限定符由包括一个或多个以下的字节：SP、HTAB、VT (%x0B)、FF (&x0C) 或者单独由 CR。但是，如果消息有多个接收端，而且这些接收端都有自己独特的健壮性的解释，那么，这种宽泛解析lenient parsing的方式会引起安全隐患（见章节 9.5）。

When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server SHOULD respond with a 400 (Bad Request) response.

当一个服务端只针对 HTTP 请求进行监听，或者正在处理 HTTP 请求消息的起始行start-line具体有什么内容的时候，接到到一个与 HTTP 消息语法不匹配的字节octets序列，除以上列出的非健壮异常以外，服务端 应该 响应一个 400 (Bad Request) 的响应消息。

The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing header fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire message.

使用 chunked 传输编码值将有效载荷payload body包裹为一系列的分块来传输。每个分块都带有单独的大小指标，跟随于一个 可选的 包含头字段的结尾之后。chunked 允许以一系列长度限定length-delimited的缓冲buffers的方式来传输大小未知的内容流。这种缓冲允许发送端去保持连接不关闭，以及使接收端得知在什么时候接收完整个消息。

chunked-body   = *chunk
                  last-chunk
                  trailer-part
                  CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                  chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF

chunk-data     = 1*OCTET ; a sequence of chunk-size octets

The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer, and finally terminated by an empty line.

其中，chunk-size 字段是一个十六进制数字的字符串，代表 chunk-data 的字节大小。当接收到一个带有 chunk-size 的值为零的分块（可以位于一个 trailer 之后并以一个空行作为结束），即代表 chunked 传输编码值是完整的。

A recipient MUST be able to parse and decode the chunked transfer coding.

一个接收端 必须 能够解析parse和解码decode chunked 传输编码值。

The codings defined below can be used to compress the payload of a message.

下列编码值能够用于对一个消息里的有效载荷payload进行压缩。

The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response, and whether or not the client is willing to accept trailer fields in a chunked transfer coding.

在一个请求消息中的头字段 TE 指明了客户端除了愿意接受 chunked 以外还愿意接受哪些传输编码的响应消息，以及客户端是否愿意在分块传输编码值中接受分块尾字段（trailer fields）。

The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as described in Section 4), and/or the keyword "trailers". A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.

TE 的字段值由一个以逗号分隔的传输编码值的名称列表组成。列表内的每一项都考虑到可选参数（见章节 4）以及/或者关键词 "trailers"。客户端 禁止 在 TE 发送 chunked 传输编码值名称；对于 HTTP/1.1 接收端来说，chunked 总是被允许的。

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
            / ( "1" [ "." 0*3("0") ] )

Three examples of TE use are below.

以下是关于 TE 的三个例子。

TE: deflate
TE:
TE: trailers, deflate;q=0.5

The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer coding, as defined in Section 4.1.2, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response.

TE 头字段里出现关键词 trailers 指明该客户端自身及其所有下游客户端都愿意在一个分块传输编码值里接受分块尾字段trailer fields（见章节 4.1.2）。对于来自一个中间人的请求，意味着以下两种情况：（a）该中间人的所有下游客户端都愿意接受分块尾字段，或者，（b）该中间人为了下游的接收端，将试图先缓冲整个响应消息。需要注意的是，HTTP/1.1 并没有对一个分块的响应消息chunked response的大小定义任何限制，因此，中间人并不能保证能够缓冲整个消息。

When multiple transfer codings are acceptable, the client MAY rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation fields, Section 5.3.1 of [RFC7231]). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable".

当允许多个传输编码值时，客户端 可以 依据其偏好，通过使用一个不区分大小写的参数 q （类似于内容协商字段里的 qvalues，见【RFC7231】章节 5.3.1），来对这些编码值分配权重。权重值是一个 0 到 1 之间的实数，最小值是 0.001（优先级最低），最大值为 1（优先级最高），排序值为 0 代表“不接受这种传输编码”。

If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with no transfer coding is always acceptable.

如果头字段 TE 不存在或者它的字段值为空，意味着仅接受 chunked 传输编码值。没有任何传输代码值的消息总是可打接受的。

Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 6.1) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.

因为头字段 TE 仅应用于直接连接immediate connection，因此，为了避免头字段 TE 被中间人转发出去（不符合 TE 的语义），TE 的发送端 必须 还要在 Connection 头字段（见章节 6.1）里发送一个 "TE" 连接选项connection option。

When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in the form of trailer fields at the end of the message, the sender SHOULD generate a Trailer header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed and the recipient wishes to confirm an integrity check on the fly.

当一个消息包含了一个使用 chunked 编码的消息体，并且发送端希望通过在消息末尾附加分块尾字段trailer fields的方式来发送元数据metadata，那么发送端 应该 在消息体之前生成一个头字段 Trailer 来指定有哪些字段将会被出现在分块尾部中。这样使得接收端在处理消息体之前可以做好接收那些元数据的准备，如果这种消息将被流式发送，并且接收端希望在接收消息的同时对其进行完整性检验，那么这种设计将非常有用。

Trailer = 1#field-name

HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification mechanism and configuration techniques as general-purpose Web browsers.

HTTP 使用于各种各样的应用中，从通用计算机到家庭应用都有 HTTP 的身影。在某些情况下，通信选项是硬编码在客户端的配置里的，但是，大多数 HTTP 客户端依靠相同的资源识别方法以及配置技术，就像通用网页浏览器一样。

HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which are defined in [RFC7231], and a target resource upon which to apply those semantics. A URI reference (Section 2.7) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing ([RFC3986], Section 3.5).

用户代理出于某种目的来初始化 HTTP 通信。该目的是由请求语义（定义在【RFC7231】），以及一个应用这些语义的目标资源target resource两者结合而成的。一个 URI 引用（URI reference，章节 2.7） 通常用于作为一个目标资源的定位符，用户代理可以将其解析resolve为绝对形式absolute form来获得“目标 URI（target URI）”。如果 URI 引用里存在段落组件 fragment 的话，目标 URI 会排除掉 fragment，这是因为 fragment 标识是保留给客户端处理的（见【RFC3986】章节 3.5）。

Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired semantics and, if so, where that request is to be directed.

一旦确定了目标 URI，客户端需要决定要想实现目标 URI 所代表的语义是否需要使用网络请求，如果是的话，请求会被导向到哪里。

If the client has a cache [RFC7234] and the request can be satisfied by it, then the request is usually directed there first.

如果客户端启用了缓存cache（【RFC7234】）并且满足该请求，那么该请求一般会优先导向到缓存里。

If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy.

如果缓存没有满足该请求，那么一个典型的客户端将会检验自身的配置来决定是否需要使用代理proxy来满足该请求。代理配置是依赖于实现implementation-dependent的，但是通常基于 URI 前缀匹配URI prefix matching、可选择的权威机构匹配selective authority matching，或者两者皆有。另外，代理自身通常是通过一个 "http" 或者 "https" URI 来标识的。如果代理是适用的，那么客户端通过建立（或复用）与该代理的连接来进行入站连接connect inbound。

If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification, similar to how this specification defines origin server access for resolution of the "http" (Section 2.7.1) and "https" (Section 2.7.2) schemes.

如果没有适用的代理，那么客户端通常会执行一个处理程序例程，这个例程通常是特定于该目标 URI 的 scheme 的，来连接到一个指向到目标资源的 authority。这个程序例程如何才算是完成取决于目标 URI 的 scheme 以及定义该 scheme 的相关规范，类似于本规范如何定义对 "http"（章节 2.7.1）和 "https"（章节 2.7.2）这两种方案的解析来访问源服务器。

译注：authority 是一个 URI 的组成部分，表现为一个服务的 DNS 主机名称或者是 IP 地址。如果该服务不是使用默认端口的话，authority 还会包含具体的端口号，其中 "http" 方案的默认端口是 80，"https" 方案的默认端口是 443。而 host 就是一个服务的 DNS 主机名称或者 IP 地址，host 并不包含端口号。也就是说：当使用默认端口时，authority = host；当不使用默认端口时，authority = host + port，两者并不等同。因此，这里将 "authority" 翻译为“主机”不合适，索性就不翻译了。

HTTP requirements regarding connection management are defined in Section 6.

关于连接管理的相关 HTTP 规范要求定义在章节 6。

Once an inbound connection is obtained, the client sends an HTTP request message (Section 3) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on both the method being requested and whether the request is to a proxy.

一旦获得了一个入站连接inbound connection，客户端会发送一个带有一个请求目标（request-target）的 HTTP 请求消息（章节 3）。请求目标从目标 URI 里推导得出。依据请求方法request method以及该请求是否是一个发送到代理proxy的请求来分，请求目标一共有四种不同的格式。

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names on a single IP address.

在一个请求消息中的 Host 头字段提供了来自目标 URI 的主机host以及端口port信息，当源服务器对同一个 IP 地址使用多个不同主机名称来处理众多请求时，Host 能够让源服务器可以区分该请求所对应的资源。

Host = uri-host [ ":" port ] ; Section 2.7.1

A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field-value.

客户端 必须 在其发送的所有 HTTP/1.1 请求消息里包含一个 Host 头字段。如果目标 URI 包含一个 authority 组件，那么客户端 必须 在其发送的请求消息里将 Host 的字段值指定为 authority 组件的内容，同时，排除掉 authority 内任何 userinfo 子组件以及它的 "@" 分隔符（章节 2.7.1）。如果目标 URI 里缺少或未定义 authority 组件，那么客户端 必须 在其发送的请求消息里包含一个字段值为空的 Host 头字段。

Since the Host field-value is critical information for handling a request, a user agent SHOULD generate Host as the first header field following the request-line.

因为对于如何处理一个请求消息来说，Host 头字段的内容是一个关键信息，所以用户代理 应该 将 Host 作为头部的第一个字段，紧随于请求行request line之后。

For example, a GET request to the origin server for http://www.example.org/pub/WWW/ would begin with:

例如，一个发送到源服务器的 GET 请求 http://www.example.org/pub/www/，其请求消息的开头为：

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.

客户端 必须 在其发送的 HTTP/1.1 请求消息里包含一个 Host 头字段，即使是绝对形式（absolute-form）的请求目标，这是因为这样做使得该 Host 的信息能够穿透那些老旧的可能未实现 Host 的 HTTP/1.0 的代理而转发出去。

译注：Host 头字段是自 HTTP/1.1 开始引入的，因此对于 HTTP/1.0 的实现而言，它就是那种“未识别的”头字段。按照 HTTP/1.0 规范【RFC1945】，未识别的头字段等同于实体头字段，见【RFC1945】章节 4.3，而对于未识别的实体头字段，接收端应该忽略，代理应该转发，见【RFC1945】章节 7.1。

When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value.

当一个代理接收到一个带有以绝对形式表示的请求目标的请求消息时，代理 必须 忽略其接收到的 Host 头字段（如果有的话），并且将其替换为请求目标的主机信息。转发这种请求的代理 必须 基于其接收到的请求目标来生成一个新的 Host 字段值，而不是直接转发原本的 Host 字段值。

Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.

因为 Host 头字段充当一个应用层的路由机制，对于恶意软件来说它是寻求攻击的一个热点目标，例如，毒害共享缓存，或者将请求重定向其他非预期的服务器当中等。在没有先验证这个被拦截的连接intercepted connection是否指向该主机的一个合法的 IP 地址的情况下，如果一个拦截代理interception proxy依赖 Host 的字段值来将请求重定向到内部服务器internal server，或者将 Host 的字段值用于作为一个共享缓存的键key来使用，那么它会特别容易受到攻击。

A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value.

如果任何 HTTP/1.1 的请求消息缺少一个 Host 头字段，或者包含超过一个以上 Host 头字段，或者 Host 的字段值不合法，那么，服务器 必须 对这种请求响应一个带有 400 (Bad Request) 状态码的响应消息。

Since the request-target often contains only part of the user agent's target URI, a server reconstructs the intended target as an "effective request URI" to properly service the request. This reconstruction involves both the server's local configuration and information communicated in the request-target, Host header field, and connection context.

因为请求目标request target通常仅包含用户代理的目标 URI 的一部分（见章节 5.3），服务器需要重建reconstruct该 URI 的预定目标来正确处理请求，这种经重建的 URI 称之为 实际请求 URI（effective request URI）。重建的过程涉及到服务器的本地配置信息，以及相关联的请求目标、Host 头字段和连接的上下文connection context。

For a user agent, the effective request URI is the target URI.

对于用户代理来说，实际请求 URI 就是目标 URI（target URI）。

If the request-target is in absolute-form, the effective request URI is the same as the request-target. Otherwise, the effective request URI is constructed as follows:

• If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the effective request URI. Otherwise, if the request is received over a TLS-secured TCP connection, the effective request URI's scheme is "https"; if not, the scheme is "http".
• If the server's configuration (or outbound gateway) provides a fixed URI authority component, that authority is used for the effective request URI. If not, then if the request-target is in authority-form, the effective request URI's authority component is the same as the request-target. If not, then if a Host header field is supplied with a non-empty field-value, the authority component is the same as the Host field-value. Otherwise, the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port number differs from the default port for the effective request URI's scheme, then a colon (":") and the incoming port number (in decimal form) are appended to the authority component.
• If the request-target is in authority-form or asterisk-form, the effective request URI's combined path and query component is empty. Otherwise, the combined path and query component is the same as the request-target.
• The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating the scheme, "://", authority, and combined path and query component.

如果请求目标是绝对形式（absolute-form），那么实际请求 URI 与请求目标（request target）相同。否则，实际请求 URI 会使用以下方式来重建：

• 如果服务器的配置信息（或者出站网关）提供了一个固定的 URI scheme，那么，这个 URI scheme 会用于参与重建实际请求 URI。没有提供固定的 URI scheme，如果该请求是在一个 TLS 安全的（TLS-secured）的 TCP 连接，那么实际请求 URI 的 scheme 为 "https"，否则，scheme 为 "http"。
• 如果服务器的配置信息（或者出站网关）提供了一个固定的 URI authority 组件，那么，这个 authority 会用于参与重建实际请求 URI。如果没有固定的 URI authority，并且如果请求目标是 authority-form 形式，那么实际请求 URI 的 authority 组件与请求目标相同，如果请求目标不是 authority-form 形式，并且如果 Host 头字段提供了一个非空的字段值，那么实际请求 URI 的 authority 组件与 Host 的字段值相同。否则，实际请求 URI 的 authority 组件会被赋值为服务器所配置的默认名称，并且如果连接的 TCP 输入端口号不是实际请求 URI 的 scheme 所对应的默认端口号，那么需要在实际请求 URI 的 authority 组件后附加一个冒号（":"）以及输入端口号（十进制形式）。
• 如果请求目标是 authority-form 或者 asterisk-form，那么实际请求 URI 的 path 和 query 组件为空。否则，path 和 query 组件与请求目标所对应的 path 和 query 相同。
• 实际请求 URI 的各个组件一旦在上述步骤中确定了，就能够通过依次连结 scheme、"://"、authority、以及 path 和 query，组合为绝对 URI（absolute-form）形式。

Example 1: the following message received over an insecure TCP connection

例一：以下消息接收于一个不安全的 TCP 连接中：

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080

has an effective request URI of

它的实际请求 URI 是：

http://www.example.org:8080/pub/WWW/TheProject.html

Example 2: the following message received over a TLS-secured TCP connection

例二：以下消息接收于一个 TLS 安全的 TCP 连接中：

OPTIONS * HTTP/1.1
Host: www.example.org

has an effective request URI of

它的实际请求 URI 是：

https://www.example.org

Recipients of an HTTP/1.0 request that lacks a Host header field might need to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess the effective request URI's authority component.

一个 HTTP/1.0 接收端，可能需要使用启发式heuristics（例如，测试 URI 的路径是否专属于某个具体主机）来猜测实际请求 URI 的 authority 组件。

Once the effective request URI has been constructed, an origin server needs to decide whether or not to provide service for that URI via the connection in which the request was received. For example, the request might have been misdirected, deliberately or accidentally, such that the information within a received request-target or Host header field differs from the host or port upon which the connection has been made. If the connection is from a trusted gateway, that inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server into delivering non-public content, or poison a cache. See Section 9 for security considerations regarding message routing.

一旦重建好了实际请求 URI，源服务器需要确定是否对这个 URI 提供服务，通过接收到该请求的连接。例如，该请求可能被误导，刻意或者意外发送到当前服务器中，以致该请求消息的请求目标或者 Host 头字段内的信息与该请求消息所对应的发送端所发起的连接的信息（主机与端口）不一致。如果该连接是来自一个可信任的网关，那么这种不一致性可能还可以接受，否则，这可能代表一个企图越过安全过滤机制，欺骗服务去分发不公开的内容，或者毒害缓存。关于消息路由的安全注意事项见章节 9。

HTTP does not include a request identifier for associating a given request message with its corresponding one or more response messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, see Section 6.2 of [RFC7231]) precede a final response to the same request.

HTTP 并不包含一个请求标记，用于关联一个给定请求消息和与之对应的一个或多个响应消息。因此，HTTP 依靠响应消息到达的顺序来一一对应在同一个连接中生成请求的顺序。出现响应消息数与请求消息数的比值大于 1 的情况仅当对该请求发送最终响应final response（任何非 1xx 状态码的响应消息）之前，对其发送了一个或多个信息性响应消息informational responses（状态码为 1xx 的响应消息，见【RFC7231】章节 6.2）。

A client that has more than one outstanding request on a connection MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non-1xx) response.

在一个连接中，如果客户端有超过一个未偿付的请求outstanding request的话，客户端 必须 以发送的顺序维护一个未完成请求的列表，并且 必须 关联每一个在该连接中接收到的响应消息到列表最高位的还未接收到最终响应（非 1xx 状态码）的请求。

As described in Section 2.3, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can enhance (or interfere) with either direction of the stream.

正如章节 2.3 所述，中间人能够在处理 HTTP 请求和响应中饰演多种角色。某些中间人是用于提升性能或可用性，另外一些用于访问控制access control或者内容过滤filter content。因为一个 HTTP 流具有类似于一个管道架构（pipe-and-filter architecture）的性质，因此，中间人对流的任何方向的提升或抑制的程度没有任何固定限制。 。

An intermediary not acting as a tunnel MUST implement the Connection header field, as specified in Section 6.1, and exclude fields from being forwarded that are only intended for the incoming connection.

不充当隧道tunnel的中间人 必须 实现章节 6.1 中所指定的 Connection 头字段，并且在转发消息时排除所有仅作用于传入连接incoming connection的字段。

An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.

中间人 禁止 转发一个消息到自身，除非它具有避免无限请求循环的保护机制。通常情况下，中间人应该了解它自身的服务器名称，包括任何别名、局部变种、文本性的 IP 地址，并将这些信息直接响应到这种请求中去。

The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message.

Connection 头字段允许发送端去指定希望如何控制当前连接的选项。为了避免下游接收端的困惑，代理或者网关 必须 在转发消息的时候移除或替换出现在该消息中的任何连接选项connection options。

译注： 连接选项connection options是一个专有名词，是特指 Connection 头字段的字段值里的内容。

When a header field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field-name within the Connection header field. A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message).

除了 Connection 头字段以外，当存在某个头字段，用于提供应用在（或者仅说明）当前连接的控制信息，发送端 必须 在 Connection 头字段里列出该头字段的名称。代理或者网关在转发消息之前，必须 解析消息里的 Connection 头字段，并且对于 Connection 头字段内的每一个连接选项 connection-option，从消息中移除与之同名的头字段，然后再移除 Connection 头字段自身（或者将其替换为中间人自己的连接选项，用于转发消息）。

译注： 原文本段的第一句 "When a header field … is used to supply control information for or about the current connection, the sender MUST …"，将 "for or about" 扩展为 "for the current connection or about the current connection"。

对于 "supply control information for the current connection"，我的理解是“对当前连接施加或设置了某些控制，然后将这些控制信息提供出来”，就像对消息的有效正文应用了某种编码，需要将该编码值添加到 Transfer-Encoding 头字段上一样。

如果接受上述的解释，那么 "supply control information about the current connection" 就很好理解了，“并没有对当前连接作新的任何控制，只是列出了当前连接有哪些控制信息”。

Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries.

因此，Connection 头字段提供了一种声明式的方式来区分哪些头字段是打算只作用于当前发送端的直接接收端的（“逐跳hop-by-hop”），哪些头字段是打算作用于链路中的所有接收端（“端到端end-to-end”）。这样，使消息能够自描述，同时，避免将来新增的连接专用的扩展connection-specific extensions被旧的（即不支持该扩展的）中间人盲转发blindly forward。

译注：Connection 内指定的头字段是仅作用于直接接收端的。关于 "hop-by-hop" 与 "end-to-end" 的解释见章节 2.1 相关的译注。

The Connection header field's value has the following grammar:

Connection 头字段的值的语法如下：

Connection        = 1#connection-option
connection-option = token

Connection options are case-insensitive.

其中，连接选项 connection-option 是不区分大小写的。

A sender MUST NOT send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, Cache-Control is never appropriate as a connection option (Section 5.2 of [RFC7234]).

发送端 禁止 发送一个与作用于所有接收端的有效载荷的头字段名称相一致的连接选项。例如，Cache-Control 是永远不能作为一个连接选项的（【RFC7234】章节 5.2）。

The connection options do not always correspond to a header field present in the message, since a connection-specific header field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific header field that is received without a corresponding connection option usually indicates that the field has been improperly forwarded by an intermediary and ought to be ignored by the recipient.

连接选项并不总是对应到某个出现在消息中的头字段的，这是因为如果这种头字段并没有字段值（即关联到某个连接选项的参数），那么它就不必出现在消息头里了。与之相对的是，如果消息中带有某个连接专用的头字段，但并不存在一个与之对应的连接选项（即 Connection 里并没有包含与这个头字段名称一致的连接选项），出现这种情况通常表明该头字段是被某个中间人错误地转发过来的，并且应该被接收端所忽略掉。

When defining new connection options, specification authors ought to survey existing header field names and ensure that the new connection option does not share the same name as an already deployed header field. Defining a new connection option essentially reserves that potential field-name for carrying additional information related to the connection option, since it would be unwise for senders to use that field-name for anything else.

当定义新的连接选项时，规范的作者们应该审视已有的头字段名称，确保新的连接选项的名称与目前已部署的头字段名称不相冲突。定义一个新的连接选项基本上会一并将同名头字段名作为保留字，用来搭载与该连接选项相关的额外信息，所以，如果发送端将这种头字段用作他用是很不明智的。

The "close" connection option is defined for a sender to signal that this connection will be closed after completion of the response. For example,

连接选项 "close" 用于发送端向接收端发出信号——当前连接将会在完成响应后被关闭。例如：

Connection: close

in either the request or the response header fields indicates that the sender is going to close the connection after the current request/response is complete (Section 6.6).

如果连接选项 "close" 出现在请求消息或者响应消息中，表明发送端将会在完成目前的请求/响应后关闭该连接（章节 6.6）。

A client that does not support persistent connections MUST send the "close" connection option in every request message.

不支持持久连接（Persistent）的客户端 必须 在其发送的每个请求消息中包含有 "close" 连接选项。

A server that does not support persistent connections MUST send the "close" connection option in every response message that does not have a 1xx (Informational) status code.

不支持持久连接服务器 必须 在其发送的每个状态码不是 1xx (Informational) 的响应消息中包含有 "close" 连接选项。

It is beyond the scope of this specification to describe how connections are established via various transport- or session-layer protocols. Each connection applies to only one transport link.

关于连接如何经由传输层或会话层协议被建立，并不在本规范探讨的范围之内。每个连接仅适用于一个传输链路。

HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. The "close" connection option is used to signal that a connection will not persist after the current request/response. HTTP implementations SHOULD support persistent connections.

HTTP/1.1 对持久连接（Persistent Connections）的使用进行了定义，允许在单个连接中搭载多个请求和响应。"close" 连接选项用于作为连接将会在当前请求/响应后不再维持的信号。HTTP 的实现implementations 应当 支持持久连接。

译注：持久连接又称为长连接。

A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and Connection header field (if any):

• If the "close" connection option is present, the connection will not persist after the current response; else,
• If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,
• If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise,
• The connection will close after the current response.

接收端基于最近接收到的消息的协议版本以及 Connection 头字段（如果有的话）来确定一个连接是否是持久连接：

• if 接收到的消息里出现 "close" 连接选项，then 连接将会在当前响应之后不再维持；
• else if 接收到的协议版本是 HTTP/1.1（或者更新），then 连接将会在当前响应之后继续维持；
• else if 接收到的协议版本是 HTTP/1.0，并且出现 "keep-alive" 连接选项，并且该接收端不是一个代理，并且该接收端希望遵循 HTTP/1.0 的 "keep-alive" 机制，then 连接将会在当前响应之后继续维持；
• else 连接将会在当前响应之后关闭。

译注：遗留问题，对连接的描述上，"not persist" 与 "close" 有什么区别？

A client MAY send additional requests on a persistent connection until it sends or receives a "close" connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.

客户端 可以 在一个持久连接中发送额外的请求消息，直到它发送或接收到一个带有 "close" 连接选项的消息，或者接收到一个没有 "keep-alive" 连接选项的 HTTP/1.0 响应消息为止。

In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 3.3. A server MUST read the entire request message body or close the connection after sending its response, since otherwise the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST read the entire response message body if it intends to reuse the same connection for a subsequent request.

为了保持持久，在一个连接中的所有消息都需要带有一个由自身所定义self-defined的消息长度（也就是说，并不是由连接的关闭而定义的那个长度），如章节 3.3 所述。服务器 必须 在发送响应消息后，读取整个请求消息体或者关闭该连接，这是因为如果不这样做的话，存在于持久连接中的剩余的数据会被误解为是下一个请求消息的内容。同样，如果客户端打算在接下来的请求中复用同一个连接，那么，客户端 必须 读取整个响应消息体。

A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).

代理服务器 禁止 与一个 HTTP/1.0 客户端维持一个持久连接（见【RFC2068】章节 19.7.1 关于某些 HTTP/1.0 客户端所实现的 Keep-Alive 头字段的问题的信息和讨论）。

See Appendix A.1.2 for more information on backwards compatibility with HTTP/1.0 clients.

关于向后兼容 HTTP/1.0 客户端的更多信息，见附录 A.1.2。

A client ought to limit the number of simultaneous open connections that it maintains to a given server.

客户端应该限制与某个给定服务器同时维持打开的连接的数量。

Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.

HTTP 早前的修订版给出了一个连接数上限的具体数值，但最终发现对于许多应用来说，这是不切实际的。所以，本规范并不指定一个详细的连接数最大值，但是，取而代之的是，鼓励客户端在开启多连接的时候尽可能的保守。

Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks.

多连接通常用于避免队头堵塞（"head-of-line blocking"）的问题，引起该问题的某个请求可能带有一个巨大的有效载荷，从而耗费了服务端很多处理时间，从而堵塞掉随后的在同一连接中的其他请求。但是，每个连接都消耗服务端资源，而且，在拥堵的网络中使用多连接可能会引发不良副作用。

Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive number of open connections from a single client.

需要注意的是，在服务器认为滥用多连接或具有拒绝服务攻击denial-of-service attack的特征的时候，服务器可能会拒绝该流量，例如，由单独一个客户端对服务器发送了过量的开启连接的请求。

Servers will usually have some timeout value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same proxy server. The use of persistent connections places no requirements on the length (or existence) of this timeout for either the client or the server.

服务器通常会带有某些超时值，如果超过该值时，服务器将不再维持一个可交互的连接。代理服务器可能会提高这些超时值的上限，这是因为很有可能客户端会通过同一个代理服务器创建更多的连接。持久连接的使用并不对客户端或服务器的超时时长（或者超时机制的存在）作任何要求。

A client or server that wishes to time out SHOULD issue a graceful close on the connection. Implementations SHOULD constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of both sides of a connection enables allocated system resources to be reclaimed.

希望超时的客户端或服务器 应当 在连接中发出一个优雅的关闭信号。所有 HTTP 实现implementations 应当 在已打开的连接中不断监听关闭信号，并且正确地响应该信号，这是因为连接两端的关闭确认可以使系统分配的资源得到回收。

A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.

客户端、服务器或者代理 可以 在任何时候关闭传输连接。例如，客户端可能刚开始去发送一个新的请求，但同时，服务器却决定关闭这个在此之前一直闲置的连接。站在服务器的立场来看，该连接将会被关闭是因为它一直闲置，但站在客户端的立场来看，连接正在传输某个请求。

A server SHOULD sustain persistent connections, when possible, and allow the underlying transport's flow-control mechanisms to resolve temporary overloads, rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.

可以的话，服务器 应当 维护持久连接，并且允许底层传输的流量控制机制去解决临时过载的问题，而不是异常中断连接让客户端去重试。后者的方式可能会加剧网络的拥堵。

A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD immediately cease transmitting the body and close its side of the connection.

客户端正在发送一个请求消息体，对应的连接正在传输客户端的请求，这时候，客户端 应当 监听网络连接中的错误响应error response。如果该客户端观察到一个响应消息，该响应消息表明服务器并不希望接收该消息体并且打算关闭这个连接，那么，客户端 应当 立即停止传输该消息体，并关闭客户端这一端的连接。

The Connection header field (Section 6.1) provides a "close" connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair.

Connection 头字段（章节 6.1）提供了一个 "close" 连接选项，如果服务器希望在完成接收请求消息并且发送相应的响应消息之后关闭连接，服务器 应当 在其发送的响应消息中包含 "close" 连接选项。

A client that sends a "close" connection option MUST NOT send further requests on that connection (after the one containing "close") and MUST close the connection after reading the final response message corresponding to this request.

客户端发送了一个带有 "close" 连接选项的请求消息之后，禁止 在该（已标记为关闭的）连接上进一步发送请求消息，并且 必须 在读取完该请求消息所对应的最后一个响应消息之后关闭这个连接。

A server that receives a "close" connection option MUST initiate a close of the connection (see below) after it sends the final response to the request that contained "close". The server SHOULD send a "close" connection option in its final response on that connection. The server MUST NOT process any further requests received on that connection.

服务器接收到一个带有 "close" 连接连接的请求消息，在其发送完该请求消息所对应的最后一个响应消息之后，必须 进行关闭连接的流程（见下文）。服务器 应当 在该连接中的最后一个响应消息中带有一个 "close" 连接选项。其后，服务器 禁止 在该连接中处理任何进一步的请求消息。

A server that sends a "close" connection option MUST initiate a close of the connection (see below) after it sends the response containing "close". The server MUST NOT process any further requests received on that connection.

服务器发送了一个带有 "close" 连接选项的响应消息之后，必须 进行关闭连接的流程（见下文）。其后，服务器 禁止 在该连接中处理任何进一步的请求消息。

A client that receives a "close" connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the "close"; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server.

客户端接收到一个带有 "close" 连接选项的响应消息之后，必须 在该连接中停止发送请求，并在读取完该响应消息之后关闭这个连接。如果额外的流水线化的请求已经被发送到连接，客户端 不应当 假设服务器会处理它们。

If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last HTTP response. If the server receives additional data from the client on a fully closed connection, such as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they can be read and interpreted by the client's HTTP parser.

如果服务器立即关闭 TCP 连接，会出现客户端将不再能够读取到最后一个 HTTP 响应的重大风险。如果服务器在一个完全关闭掉的连接中接收到来自客户端所发送的额外数据，例如客户端在接收到服务器的响应之前发送了其他请求，那么，服务器的 TCP 栈（TCP stack）将会发送一个重置消息数据包（Reset Packet）到该客户端；不幸的是，在客户端的未确认输入缓冲区unacknowledged input buffers能够被客户端的 HTTP 解析器读取并解释interpret之前，该缓冲区的数据可能会被这个重置数据包所抹去。

To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by closing only the write side of the read/write connection. The server then continues to read from the connection until it receives a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection.

为了避免 TCP 连接重置的问题，服务器一般会分阶段关闭一个连接。首先，服务器通过仅仅关闭该连接的写入端（一个连接有读/写两端）来实现连接的“半关闭half-close”。然后，服务器继续读取连接里的数据，直到服务器接收到一个来自客户端的关闭信号，或者直到服务器有理由确认它自身的 TCP 栈已经接收到来自客户端的确认数据包。最后，服务器完全关闭这个连接。

It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.

目前并不知道重置问题是否是 TCP 协议独有的，也有可能出现在其他传输连接协议上。

The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot be used to insist on a protocol change.

Upgrade 头字段是打算提供一个简单的方式来将同一个连接中的 HTTP/1.1 消息过渡到其他协议消息。客户端 可以 在其发送的请求消息中带有一个包含一系列协议的 Upgrade 头字段，来邀请invite服务器在发送最终响应之前，将响应消息切换到一个或多个上述的协议，按优先级从高到低排序descending preference。服务器 可以 忽略其接收到的 Upgrade 头字段，如果它希望继续在该连接中使用当前协议的话。Upgrade 不能用于督促insist on服务器改变协议。

译注：客户端可以“建议”服务器改变协议，但不能“要求”服务器改变协议。

Upgrade          = 1#protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

A server that sends a 101 (Switching Protocols) response MUST send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol layers are being switched, the sender MUST list the protocols in layer-ascending order. A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server MAY choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such as the nature of the request or the current load on the server.

服务器发送一个带有 101 (Switching Protocols) 状态码的响应消息时，必须 带有一个 Upgrade 头字段用于指定连接将会被切换到哪一种（或多种）新的协议上。如果将会切换多个协议层，发送端 必须 按协议层从低到高的顺序Layer-ascending列出这些协议。服务器 禁止 切换到一个未被客户端（在对应的请求消息中的 Upgrade 头字段）所指定的协议。服务器 可以 选择忽略掉客户端所指定优先级顺序，依据其他因素来选择需要切换到哪一种的协议上，例如依据请求的性质或者当前服务器的负荷来选择。

A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending preference.

服务器发送了一个带有 426 (Upgrade Required) 状态码的响应消息时，必须 带有一个 Upgrade 头字段用于指定服务器可接受切换到哪些协议，按优先级从高到低排序。

A server MAY send an Upgrade header field in any other response to advertise that it implements support for upgrading to the listed protocols, in order of descending preference, when appropriate for a future request.

服务器 可以 在其他响应消息（也就是说该响应消息所对应的请求消息并未带有 Upgrade 头字段）中带有 Upgrade 头字段，来声明服务器自身所支持的协议列表，按优先级从高到低排序，用于通知客户端将来使用哪些协议来发送请求更合适。

The following is a hypothetical example sent by a client:

假设某个客户端发送了以下一个请求消息：

GET /hello.txt HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

The capabilities and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s) chosen. However, immediately after sending the 101 (Switching Protocols) response, the server is expected to continue responding to the original request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).

在协议变更以后，应用层通信的能力和性质取决于所选择的（一个或多个）新协议上。但是，在服务器直接发送了一个带有 101 (Switching Protocols) 状态码的过渡性响应interim response之后，服务器需要继续发送一个最终响应final response给到原先的请求，就像服务器已经在新协议连接中接收到请求消息一样（也就是说，在协议已经变更以后，服务器仍然存在一个未偿付的请求在等待满足，服务器打算以新的协议形式来满足这个请求，而不需要让客户端以新的协议形式来再一次发送该请求）

译注：也就是说，在向客户端发送 101 (Switching Protocols) 过渡性响应之后就算真正切换到新协议了，但是，虽然在协议变更了，该服务器仍然未向客户端发送最终响应，因此，服务器需要以新的协议形式来响应这个请求，而不需要让客户端以新的协议形式来再一次发送该请求。

For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first responds with a 101 (Switching Protocols) message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of an additional round trip. A server MUST NOT switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored by any protocol.

例如，服务器接收到一个 GET 请求消息，带有一个 Upgrade 头字段的，服务器决定切换协议，它首先使用 HTTP/1.1 协议响应一个 101 (Switching Protocols) 过渡性消息给到该请求，然后马上再以新协议的方式响应目标资源给到该请求。这样使得连接的协议能够以 HTTP 相同的语义来进行更新，而没有带来额外消息往返的延迟成本。服务器 禁止 切换协议，除非其接收到的消息语义能够被新协议所遵循；一个 OPTIONS 请求能够被任何协议所遵循。

The following is an example response to the above hypothetical request:

以下消息样例是对应上述假设的请求消息的响应消息：

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: HTTP/2.0

[... data stream switches to HTTP/2.0 with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...]

When Upgrade is sent, the sender MUST also send a Connection header field (Section 6.1) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries that might not implement the listed protocols. A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.

当发送一个带有 Upgrade 头字段的消息时，发送端 必须 使该消息同时带上一个包含有一个 "upgrade" 连接选项的 Connection 头字段（章节 6.1），以免 Upgrade 头字段被没有实现这些协议的中间人意外转发出去。服务端 必须 忽略接收自一个 HTTP/1.0 请求消息的 Upgrade 头字段。

A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message). If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response.

客户端不能在连接中使用新的协议，直到它将当前的请求消息的完整地发送出去（也就是说，客户端不能在发送一个消息的中途改变协议）。如果服务器接收到一个请求消息，既带有一个 Upgrade 头字段，也带有一个 "100-continue" 期望值expectation的 Expect 头字段（【RFC7231】章节 5.1.1）的时候，服务器 必须 在发送一个 101 (Switching Protocols) 响应消息之前，发送一个 100 (Continue) 响应消息。

The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those purposes, it is more appropriate to use a 3xx (Redirection) response (Section 6.4 of [RFC7231]).

Upgrade 头字段仅应用于切换现有最顶层的连接所使用的协议，它并不能用于切换底层的连接（传输）协议，也不能用于将目前的通信切换到其他不同的连接之上。要达到上述的其他目的，使用一个 3xx (Redirection) 响应会更加合适（【RFC7231】章节 6.4）。

译注：Upgrade 既不能切换底层协议，也不能切换当前的连接，它只能切换当前连接所使用的协议。

This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 2.6 and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure defined in Section 8.6.

按照章节 2.6 中 HTTP 版本规则所定义的，以及将来对本规范的更新，本规范仅定义提供给超文传输协议家族使用的的协议名称 "HTTP"。更多的标记应该使用定义在章节 8.6 的登记手续到 IANA 进行登记。

HTTP header fields are registered within the "Message Headers" registry maintained at http://www.iana.org/assignments/message-headers/.

This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

Furthermore, the header field-name "Close" has been registered as "reserved", since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.1).

The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

IANA maintains the registry of URI Schemes [BCP115] at http://www.iana.org/assignments/uri-schemes/.

This document defines the following URI schemes, so the "Permanent URI Schemes" registry has been updated accordingly.

IANA maintains the registry of Internet media types [BCP13] at http://www.iana.org/assignments/media-types.

This document serves as the specification for the Internet media types "message/http" and "application/http". The following has been registered with IANA.

The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at http://www.iana.org/assignments/http-parameters.

IANA maintains the "HTTP Content Coding Registry" at http://www.iana.org/assignments/http-parameters.

The "HTTP Content Coding Registry" has been updated with the registrations below:

The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at http://www.iana.org/assignments/http-upgrade-tokens.

HTTP relies on the notion of an authoritative response: a response that has been determined by (or at the direction of) the authority identified within the target URI to be the most appropriate response for that request given the state of the target resource at the time of response message origination. Providing a response from a non-authoritative source, such as a shared cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or the distrusted response can be safely used.

HTTP 提出了一个“权威响应authoritative response”的概念——由目标 URI 所表明的 authority （权威机构、官方机构）所决定（或指导）的最合适于这个请求的一种响应。它给出了诞生响应消息那时候的目标资源状态。提供自一个非权威来源non-authoritative source——例如一个共享缓存——的响应，一般对于提升性能和可用性有很大作用，但是仅在该来源是受信任的或者该不受信任的响应可以被安全地使用的情况。

译注： "authoritative response" 译为“权威响应”、“官方响应”，也就是说，这种响应是来自客户端所期望的那一个源服务器的，而且其有效载荷没有被任何中间人修改（编码）过的。 另外，"authoritative" 是“有权威的，当局的，官方的”的意思，但并没有“授权”、“认证”的意思！某些人将 "authoritative response" 译为“授权响应、认证响应”都是错误的，个人认为是弄混了 "authority"，"authentication"，"certification"，"verification" 这几个单词的意思，例如 "certificate authority" 是“认证中心、认证机构”。

Unfortunately, establishing authority can be difficult. For example, phishing is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in hypertext, possibly aided by userinfo obfuscating the authority component (see Section 2.7.1). User agents can reduce the impact of phishing attacks by enabling users to easily inspect a target URI prior to making an action, by prominently distinguishing (or rejecting) userinfo when present, and by not sending stored credentials and cookies when the referring document is from an unknown or untrusted source.

不幸的是，确立 authority 不是一个容易的事。例如，钓鱼phishing是一种针对用户对于 authority 的认知perception的攻击，这种认知可能会因为在超文本里出现了相似的品牌branding，可能还会辅以 userinfo 来对 authority 组件进行混淆（见章节 2.7.1），从而造成误导。用户代理能够通过提供一种途径，让用户在执行操作之前可以轻易检测某个目标 URI 的真伪，来降低钓鱼攻击的影响。例如，明显区分（或拒绝） userinfo 组件的出现，并且当所指向的文档是来自某个未知或不受信任的来源的时候，不对其发送存储在客户端的授权证书和 cookies。

When a registered name is used in the authority component, the "http" URI scheme (Section 2.7.1) relies on the user's local name resolution service to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority. Likewise, the user's choice of server for Domain Name Service (DNS), and the hierarchy of servers from which it obtains resolution results, could impact the authenticity of address mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to improve authenticity.

当某个已登记的名称用在 authority 组件中的时候，"http" URI 方案（章节 2.7.1）依靠用户的本地名称解析服务来确定哪里能够找到权威响应authoritative responses。这意味着任何对于用户的网络主机映射表network host table、缓存名称，或者名称解析库的攻击都会成为一个攻击确立权威的隐患。同样，用户选择哪一个服务器用于域名解析服务domain name service（DNS），以及其获取域名解析结果的服务器所在层级，都有可能影响到地址映射的可靠性。DNS 安全性扩展DNS Security Extensions（DNSSEC，【RFC4033】）是一种提高可靠性的方式。

Furthermore, after an IP address is obtained, establishing authority for an "http" URI is vulnerable to attacks on Internet Protocol routing.

另外，在获得一个 IP 地址之后，确立一个 "http" URI 的 authority 在 IP 协议Internet Protocol路由方面也存在被攻击的风险。

The "https" scheme (Section 2.7.2) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, provided that the negotiated TLS connection is secured and the client properly verifies that the communicating server's identity matches the target URI's authority component (see [RFC2818]). Correctly implementing such verification can be difficult (see [Georgiev]).

"https" 方案（章节 2.7.2）是意图避免（或者至少揭露）上述这些对于确立权威方面的潜在攻击，它提供了一种协商的的安全 TLS 连接，同时让客户端能够正确验证当前通信的服务器的身份是否与目标 URI 的 authority 组件相匹配（见【RFC2818】）。正确实现这种验证可能不是一件容易的事（见【Georgiev】）。

By their very nature, HTTP intermediaries are men-in-the-middle and, thus, represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries might have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.

就其本质而言，HTTP 中间人intermediaries就是一种“中间人men-in-the-middle”，由此，为中间人提供了攻击的机会。如果泄漏了运行于中间人上的系统，可能会导致严重的安全和隐私问题。中间人可能能够访问安全相关的信息、个人用户或组织的个人信息，以及属于用户或内容提供商的专有信息。一个已泄漏出去的中间人，或者一个没有实现或没有配置关于安全和隐私方面的注意事项的中间人，可能会被用于各种潜在攻击。

Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 8 of [RFC7234].

包含了一个共享缓存的中间人特别容易受到缓存中毒攻击cache poisoning attacks，正如【RFC7234】章节 8 所述那样。

Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to operators (especially the default configuration).

实现者implementers需要去思考他们的设计以及编码决策，以及提供给使用者operators的配置选项（特别是默认配置）所蕴含的隐私性和安全性。

Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem.

用户需要被告知中间人并不见得比运行它们的人们更加值得信赖。HTTP 本身并不能解决这种问题。

Because HTTP uses mostly textual, character-delimited fields, parsers are often vulnerable to attacks based on sending very long (or very slow) streams of data, particularly where an implementation is expecting a protocol element with no predefined length.

因为 HTTP 使用的主要是文本性的、以字符分隔的字段，因此，解析器parser常常受到基于发送非常长（或非常慢）的数据流的方式的攻击，特别是在一个中间人期望某个没有预定义长度的协议元素身上。

To promote interoperability, specific recommendations are made for minimum size limits on request-line (Section 3.1.1) and header fields (Section 3.2). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.

为了提高互操作性，本规范提出了对于请求行（章节 3.1.1）以及头字段（章节 3.2）的最小值限制的具体建议。这些最小值建议，本规范选择的是即使资源受限的实现implementations也能够支持的，期望大多数的实现会选择更大幅度的限制。

A server can reject a message that has a request-target that is too long (Section 6.5.12 of [RFC7231]) or a request payload that is too large (Section 6.5.11 of [RFC7231]). Additional status codes related to capacity limits have been defined by extensions to HTTP [RFC6585].

服务器能够拒绝一个带有过长的请求目标（【RFC7231】章节 6.5.12），或者过大的请求有效载荷（【RFC7231】章节 6.5.11）的消息。作为对 HTTP 的扩展，额外的关于容量限制的响应状态码已经定义在【RFC6585】。

Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to) request methods, response status phrases, header field-names, numeric values, and body chunks. Failure to limit such processing can result in buffer overflows, arithmetic overflows, or increased vulnerability to denial-of-service attacks.

接收端应该小心地限制其处理的除上述以外的其他协议元素的大小，包括（但不限于）请求方法，响应状态短语，头字段的名称，数字值以及消息分块。

Response splitting (a.k.a, CRLF injection) is a common technique, used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections [Klein]. This technique can be particularly damaging when the requests pass through a shared cache.

响应分割（Response Splitting，也称为“CRLF 注入”）是一种针对网页用途Web usage而进行各种攻击的常见的技术，它利用了 HTTP 基于行line-based来进行消息分帧，以及在持久连接中请求与响应的顺序关联的性质【Klein】。当请求穿过一个共享缓存的时候，这种技术特别具有破坏性。

Response splitting exploits a vulnerability in servers (usually within an application server) where an attacker can send encoded data within some parameter of the request that is later decoded and echoed within any of the response header fields of the response. If the decoded data is crafted to look like the response has ended and a subsequent response has begun, the response has been split and the content within the apparent second response is controlled by the attacker. The attacker can then make any other request on the same persistent connection and trick the recipients (including intermediaries) into believing that the second half of the split is an authoritative answer to the second request.

响应分割利用了服务器（通常在一个应用服务器内）的一个弱点，攻击者能够在某些请求参数里带有经过编码的数据，而这些参数并不会在服务器立即解码，而是回显echo至对应的响应消息的头字段里。如果解码数据被精心设计得看起来像是该响应消息的结束以及后续消息的开始，那么该响应消息就被“分割”为前后两个响应消息，并且后一个“响应消息”（表面上看像是一个响应消息，但实际是原响应消息的后半部分）受控于攻击者。然后攻击者就能够在同一个持久连接中做任何请求并欺骗接收端（包括中间人）让它们相信分割过的后半部分是第二个请求的权威应答authoritative answer。

For example, a parameter within the request-target might be read by an application server and reused within a redirect, resulting in the same parameter being echoed in the Location header field of the response. If the parameter is decoded by the application and not properly encoded when placed in the response field, the attacker can send encoded CRLF octets and other content that will make the application's single response look like two or more responses.

例如，在请求目标内的一个参数可能会被一个应用服务器所读取，并复用在一个重定义响应内，导致同一个参数被回显到响应消息的 Location 头字段内。如果该参数由客户端应用负责解码，而且服务器在将该参数放置到响应头字段的时候没有正确地对其编码，那么，攻击者能够发送多个编码过的 CRLF 字节以及其他内容来让该应用的单一响应消息看起来像是两个或多个响应消息。

A common defense against response splitting is to filter requests for data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). However, that assumes the application server is only performing URI decoding, rather than more obscure data transformations like charset transcoding, XML entity translation, base64 decoding, sprintf reformatting, etc. A more effective mitigation is to prevent anything other than the server's core protocol libraries from sending a CR or LF within the header section, which means restricting the output of header fields to APIs that filter for bad octets and not allowing application servers to write directly to the protocol stream.

预防响应分割的一个常见方式是去过滤掉请求消息中看起来像是经过编码的 CR 以及 LF 的数据（例如，"%0D" 和 "%0A"）。但是，假设应用服务器仅执行 URI 解码decoding，而不是更加模糊的数据转换，例如，字符集转码charset transcoding，XML 实体翻译XML entity translation，base64 解码，sprintf 字符串格式转换reformatting等等，一个更有效的缓解方式是阻止任何除了服务器自身的核心协议库以外的程序在消息头部中发送一个 CR 或者 LF，这样做意味着将对头字段的输出限制为只能使用 API 的方式，通过这些 API 来过滤掉不好的字节，同时不允许应用服务器越过 API 将数据直接写入到协议流。

Request smuggling ([Linhart]) is a technique that exploits differences in protocol parsing among various recipients to hide additional requests (which might otherwise be blocked or disabled by policy) within an apparently harmless request. Like response splitting, request smuggling can lead to a variety of attacks on HTTP usage.

请求走私（Request Smuggling）是一种利用多个接收端对 HTTP 消息解析的不一致性，来达到在一个表面无害的请求里隐藏（按正常规则来说应该被阻止或者禁止的）额外请求的技术。像响应分割response splitting一样，请求走私能够引发针对 HTTP 用途的各种攻击。

This specification has introduced new requirements on request parsing, particularly with regard to message framing in Section 3.3.3, to reduce the effectiveness of request smuggling.

本规范对请求解析request parsing引入了新的要求，特别是在消息分帧message framing方面（章节 3.3.3），以降低请求走私的影响。

HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Additional integrity mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via extensible metadata header fields. Historically, the lack of a single integrity mechanism has been justified by the informal nature of most HTTP communication. However, the prevalence of HTTP as an information access mechanism has resulted in its increasing use within environments where verification of message integrity is crucial.

HTTP 并没有定义一个具体方法来保证消息的完整性，而是依靠底层传输协议的错误检测能力error-detection ability以及使用长度或块限定的分帧chunk-delimited framing来检测完整。如果想添加额外的完整性机制，例如对内容应用哈希函数或者数字签名digital sinatures，可以通过使用可扩展的元数据头字段extensible metadata header fields来选择性地将这些额外的完整性机制应用到消息。

User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such that those means can be enabled within environments for which integrity is necessary. For example, a browser being used to view medical history or drug interaction information needs to indicate to the user when such information is detected by the protocol to be incomplete, expired, or corrupted during transfer. Such mechanisms might be selectively enabled via user agent extensions or the presence of message integrity metadata in a response. At a minimum, user agents ought to provide some indication that allows a user to distinguish between a complete and incomplete response message (Section 3.4) when such verification is desired.

鼓励用户代理去实现某些可配置的方式来对消息完整性进行检测和错误报告，以使这些方式能够在必要的情形下被启用。例如，一个浏览器被用于浏览病史，或者药物相互作信息，当协议检测到这些信息在传输过程中因为某些因素导致不完整、过期，或者损坏的时候，浏览器需要向用户指出来。这些方式可能通过用户代理的扩展程序，或者某个响应中的消息完整性元数据的出现，来被选择性地启用。至少在需要进行完整性验证的时候，用户代理应该提供某些指示来让某个用户区分到完整和不完整的响应消息（章节 3.4）

HTTP relies on underlying transport protocols to provide message confidentiality when that is desired. HTTP has been specifically designed to be independent of the transport protocol, such that it can be used over many different forms of encrypted connection, with the selection of such transports being identified by the choice of URI scheme or within user agent configuration.

HTTP 依靠底层传输协议在需要的时候提供消息保密性的保障。HTTP 已被专门设计为不依赖传输协议，使其能够应用在多种不同类型的加密连接之上。与 HTTP 一同被应用的还有由 URI 方案的选取或用户代理的配置所决定的传输方式的相关选项。

The "https" scheme can be used to identify resources that require a confidential connection, as described in Section 2.7.2.

"https" 方案能够用于标识那些要求在受信任的连接中使用的资源，正如章节 2.7.2 描述的那样。

A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction, across a multitude of sites, that can be traced to individual users.

服务器应该将用户的请求的某些个人信息随时处在保护的状态中，这是由于借由这些信息可以鉴定他们的读取模式或者兴趣订阅。实际上，聚集在中间人里的日志信息通常会包含用户代理与众多网站之间的交互历史，同样可能会被追踪到个人用户。

HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within individual entries helps, but it is generally not sufficient to prevent real log traces from being re-identified based on correlation with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if the key is pseudonymous.

HTTP 日志信息如个涉及机密信息，日志信息需要被安全地存储，对它们的分析需要遵循正确的指导方针。对个人信息进行匿名化是有效的，但这样做还不足以阻止通过关联其他访问特征来重新识别出真实的日志痕迹的行为。因此，公布具有唯一定位一个具体客户端的访问痕迹access traces是危险的，即使这个唯一码只是一个化名。

To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information, including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary to support operational needs for security, auditing, or fraud control.

为了最小化的风险，对于日志信息里的可识别信息indentifiable information，包含用户标识符user identifiers、IP 地址，以及用户提供的查询参数query parameters，一旦不再需要运用这些信息来支持安全、审计，或者防欺诈fraud control需求的运作的时候，应当及时清除掉。

[RFC0793]

Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.

[RFC1950]

Deutsch, L. and J-L. Gailly, “ZLIB Compressed Data Format Specification version 3.3”, RFC 1950, May 1996.

[RFC1951]

Deutsch, P., “DEFLATE Compressed Data Format Specification version 1.3”, RFC 1951, May 1996.

[RFC1952]

Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, “GZIP file format specification version 4.3”, RFC 1952, May 1996.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.

[RFC7231]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014.

[RFC7232]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, June 2014.

[RFC7233]

Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, RFC 7233, June 2014.

[RFC7234]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, June 2014.

[RFC7235]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, June 2014.

[USASCII]

American National Standards Institute, “Coded Character Set – 7-bit American Standard Code for Information Interchange”, ANSI X3.4, 1986.

[Welch]

Welch, T., “A Technique for High-Performance Data Compression”, IEEE Computer 17(6), June 1984.

[BCP115]

Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes”, BCP 115, RFC 4395, February 2006.

[BCP13]

Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, January 2013.

[BCP90]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

[Georgiev]

Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, “The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software”, In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49, October 2012, http://doi.acm.org/10.1145/2382196.2382204.

[ISO-8859-1]

International Organization for Standardization, “Information technology – 8-bit single-byte coded graphic character sets – Part 1: Latin alphabet No. 1”, ISO/IEC 8859-1:1998, 1998.

[Klein]

Klein, A., “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics”, March 2004, http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf.

[Kri2001]

Kristol, D., “HTTP Cookies: Standards, Privacy, and Politics”, ACM Transactions on Internet Technology 1(2), November 2001, http://arxiv.org/abs/cs.SE/0105018.

[Linhart]

Linhart, C., Klein, A., Heled, R., and S. Orrin, “HTTP Request Smuggling”, June 2005, http://www.watchfire.com/news/whitepapers.aspx.

[RFC1919]

Chatel, M., “Classical versus Transparent IP Proxies”, RFC 1919, March 1996.

[RFC1945]

Berners-Lee, T., Fielding, R., and H. Nielsen, “Hypertext Transfer Protocol – HTTP/1.0”, RFC 1945, May 1996.

[RFC2045]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.

[RFC2047]

Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”, RFC 2047, November 1996.

[RFC2068]

Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2068, January 1997.

[RFC2145]

Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, “Use and Interpretation of HTTP Version Numbers”, RFC 2145, May 1997.

[RFC2616]

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.

[RFC2817]

Khare, R. and S. Lawrence, “Upgrading to TLS Within HTTP/1.1”, RFC 2817, May 2000.

[RFC2818]

Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.

[RFC3040]

Cooper, I., Melve, I., and G. Tomlinson, “Internet Web Replication and Caching Taxonomy”, RFC 3040, January 2001.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, March 2005.

[RFC4559]

Jaganathan, K., Zhu, L., and J. Brezak, “SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows”, RFC 4559, June 2006.

[RFC5226]

Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC5246]

Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, August 2008.

[RFC5322]

Resnick, P., “Internet Message Format”, RFC 5322, October 2008.

[RFC6265]

Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011.

[RFC6585]

Nottingham, M. and R. Fielding, “Additional HTTP Status Codes”, RFC 6585, April 2012.

This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.

本章节总结了 HTTP/1.0 与 HTTP/1.1 的主要区别。

HTTP's approach to error handling has been explained. (Section 2.5)

明确了 HTTP 的错误处理方法。（章节 2.5）

The HTTP- version ABNF production has been clarified to be case-sensitive. Additionally, version numbers have been restricted to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (Section 2.6)

明确了 HTTP-version ABNF 规则为区分大小写。另外，限制了版本号的数值为一位数字single digits，这是基于已知实现implementations不能正确处理版本号为多位数字的事实来做的改动。

Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. (Section 2.7.1)

现在，不再允许在 HTTP 和 HTTPS URI 中出现 userinfo （也就是说，用户名和密码）了，因为它在通信线路上传输时存在安全问题。（章节 2.7.1）

The HTTPS URI scheme is now defined by this specification; previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it implies end-to-end security. (Section 2.7.2)

现在，HTTPS URI 方案已经被定义在本规范中。以前，它是定义在【RFC2818】章节 2.4 中。此外，HTTPS 意味着端到端安全。（章节 2.7.2）

HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve interoperability. (Section 3)

HTTP 消息能够（而且通常会）被缓冲buffer，尽管它有时候作为流的形式来提供，HTTP 本质上来说是一种面向消息的协议message-oriented protocol。为了提高互操作性，本规则建议了各种协议元素的最小可支持的大小。（章节 3）

Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. The ABNF productions defining header fields now only list the field value. (Section 3.2)

现在，字段名称field-names两端不能出现非法的空白字符，这是因为允许它们就意味着安全隐患。现在，定义头字段的 ABNF 规则 header-field 只列出了 field-value。（章节 3.2）

译注：【RFC2616】对消息字段的 ABNF 定义在这里（message-header）；【RFC7231】对头字段的 ABNF 定义在这里（header-field）。

Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed where specifically defined in the ABNF. (Section 3.2.3)

移除了某些暗示连续空白的相关语法规则，现在，空白只允许在 ABNF 中有明确定义的地方。（章节 3.2.3）

Header fields that span multiple lines ("line folding") are deprecated. (Section 3.2.4)

废弃了能够横跨多行（折叠行line folding）的头字段。（章节 3.2.4）

The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-US-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)

NUL 字节不再允许出现在 comment （注释）和 quoted-string （以双引号包裹的字符串）里，同时，明确了使用反斜杠转义 NUL 字节的处理方式。quoted-pair 规则不再允许转义除 HTAB 以外的控制字符（Control Characters）。在头字段（header fields）和 reason-phrase 中存在的非 USASCII 的内容已被弃用，并将其设置为不透明数据（移除了 TEXT 规则）。（章节 3.2.6）

译注：关于不透明数据的解释见章节 3.2.4。

Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2)

现在，要求接收端将伪造的 Content-Length 头字段作为错误来处理。（章节 3.3.2）

The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. CONNECT is a new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body length detection. (Section 3.3.3)

明确指出了所有影响确定消息体长度的算法的所有特殊情况（例如，由方法或状态码决定），并且，将来新增的协议元素不能再定义这种特殊情况。CONNECT 是新加入的影响消息体长度的特殊情况。"multipart/byteranges" 不再是一种确定消息体长度的检测方式。（章节 3.3.3）

The "identity" transfer coding token has been removed. (Sections 3.3 and 4)

移除了 "identity" 传输编码值。（章节 3.3 以及 章节 4）

Chunk length does not include the count of the octets in the chunk header and trailer. Line folding in chunk extensions is disallowed. (Section 4.1)

分块头部chunk header和分块尾部trailer内的字节不计入分块chunk的长度。块扩展chunk extensions不允许折叠行line folding。（章节 4.1）

The meaning of the "deflate" content coding has been clarified. (Section 4.2.2)

明确了 "deflate" 内容编码值的意思。（章节 4.2.2）

The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. The asterisk-form of the request-target is only allowed with the OPTIONS method. (Section 5.3)

使用 【RFC3986】里的 segment 和 query 组件来定义 request-target，而不再是【RFC1808】里的 abs_path。request-target 的星号形式（asterisk-form）仅允许用于 OPTIONS 请求方法。（章节 5.3）

The term "Effective Request URI" has been introduced. (Section 5.5)

引入了术语 实际请求 URI（effective request URI）。（章节 5.5）

Gateways do not need to generate Via header fields anymore. (Section 5.7.1)

网关不再需要生成 Via 头字段了。（章节 5.7.1）

Exactly when "close" connection options have to be sent has been clarified. Also, "hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt them. (Section 6.1)

明确了何时需要发送 "close" 连接选项connection options的时机。同时，要求“逐跳hop-by-hop”类型的头字段出现在 Connection 头字段内，被本规范定义为“逐跳”类型的头字段，同样不能豁免这个要求。（章节 6.1）

The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried. The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (Section 6.3)

移除了每个服务器两个连接的限制。一个幂等的请求序列不再需要重试。移除了当服务器过早关闭连接时，在特定环境下要求重试请求的要求。同样，移除了某些关于何时允许服务器能过早地关闭连接的无关的要求。（章节 6.3）

The semantics of the Upgrade header field is now defined in responses other than 101 (this was incorporated from [RFC2817]). Furthermore, the ordering in the field value is now significant. (Section 6.7)

Upgrade 头字段的语义现在定义在响应里，而不再是 101（来自【RFC2817】，这是不正确的）。而且，它的字段值的顺序现在是有意义的。（章节 6.7）

Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (Section 7)

废弃了列表类型的值里允许出现空元素的规则（例如，一个列表类型的头字段，包含 ", ,"）。（章节 7）

Registration of Transfer Codings now requires IETF Review (Section 8.4)

登记传输编码值transfer codings现在需要经过 IETF 的复审。（章节 8.4）

This specification now defines the Upgrade Token Registry, previously defined in Section 7.2 of [RFC2817]. (Section 8.6)

本规范现在定义了升级标记登记表（Upgrade Token Registry），之前是定义在【RFC2817】章节 7.2 里的。（章节 8.6）

The expectation to support HTTP/0.9 requests has been removed. (Appendix A)

移除了期望支持 HTTP/0.9 请求的相关描述。（附录 A）

Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged altogether. (Appendix A.1.2)

指出了与请求里的 Keep-Alive 和 Proxy-Connection 头字段相关的问题，以及对于后者的使用完全失去信心。（附录 A.1.2）