Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7230 Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed.
Updates: 2817, 2818 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7230 Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed.
Updates: 2817, 2818 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
超文本传输协议（HTTP/1.1）：消息语法和路由
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
超文本传输协议（HTTP）是用于分布式、协作式超文本信息系统的无状态应用程序级协议。本文档概述了HTTP体系结构及其相关术语，定义了“HTTP”和“https”统一资源标识符（URI）方案，定义了HTTP/1.1消息语法和解析要求，并描述了实现的相关安全问题。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7230.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7230.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Requirements Notation ......................................6
1.2. Syntax Notation ............................................6
2. Architecture ....................................................6
2.1. Client/Server Messaging ....................................7
2.2. Implementation Diversity ...................................8
2.3. Intermediaries .............................................9
2.4. Caches ....................................................11
2.5. Conformance and Error Handling ............................12
2.6. Protocol Versioning .......................................13
2.7. Uniform Resource Identifiers ..............................16
2.7.1. http URI Scheme ....................................17
2.7.2. https URI Scheme ...................................18
2.7.3. http and https URI Normalization and Comparison ....19
3. Message Format .................................................19
3.1. Start Line ................................................20
3.1.1. Request Line .......................................21
3.1.2. Status Line ........................................22
3.2. Header Fields .............................................22
1. Introduction ....................................................5
1.1. Requirements Notation ......................................6
1.2. Syntax Notation ............................................6
2. Architecture ....................................................6
2.1. Client/Server Messaging ....................................7
2.2. Implementation Diversity ...................................8
2.3. Intermediaries .............................................9
2.4. Caches ....................................................11
2.5. Conformance and Error Handling ............................12
2.6. Protocol Versioning .......................................13
2.7. Uniform Resource Identifiers ..............................16
2.7.1. http URI Scheme ....................................17
2.7.2. https URI Scheme ...................................18
2.7.3. http and https URI Normalization and Comparison ....19
3. Message Format .................................................19
3.1. Start Line ................................................20
3.1.1. Request Line .......................................21
3.1.2. Status Line ........................................22
3.2. Header Fields .............................................22
3.2.1. Field Extensibility ................................23
3.2.2. Field Order ........................................23
3.2.3. Whitespace .........................................24
3.2.4. Field Parsing ......................................25
3.2.5. Field Limits .......................................26
3.2.6. Field Value Components .............................27
3.3. Message Body ..............................................28
3.3.1. Transfer-Encoding ..................................28
3.3.2. Content-Length .....................................30
3.3.3. Message Body Length ................................32
3.4. Handling Incomplete Messages ..............................34
3.5. Message Parsing Robustness ................................34
4. Transfer Codings ...............................................35
4.1. Chunked Transfer Coding ...................................36
4.1.1. Chunk Extensions ...................................36
4.1.2. Chunked Trailer Part ...............................37
4.1.3. Decoding Chunked ...................................38
4.2. Compression Codings .......................................38
4.2.1. Compress Coding ....................................38
4.2.2. Deflate Coding .....................................38
4.2.3. Gzip Coding ........................................39
4.3. TE ........................................................39
4.4. Trailer ...................................................40
5. Message Routing ................................................40
5.1. Identifying a Target Resource .............................40
5.2. Connecting Inbound ........................................41
5.3. Request Target ............................................41
5.3.1. origin-form ........................................42
5.3.2. absolute-form ......................................42
5.3.3. authority-form .....................................43
5.3.4. asterisk-form ......................................43
5.4. Host ......................................................44
5.5. Effective Request URI .....................................45
5.6. Associating a Response to a Request .......................46
5.7. Message Forwarding ........................................47
5.7.1. Via ................................................47
5.7.2. Transformations ....................................49
6. Connection Management ..........................................50
6.1. Connection ................................................51
6.2. Establishment .............................................52
6.3. Persistence ...............................................52
6.3.1. Retrying Requests ..................................53
6.3.2. Pipelining .........................................54
6.4. Concurrency ...............................................55
6.5. Failures and Timeouts .....................................55
6.6. Tear-down .................................................56
6.7. Upgrade ...................................................57
7. ABNF List Extension: #rule .....................................59
3.2.1. Field Extensibility ................................23
3.2.2. Field Order ........................................23
3.2.3. Whitespace .........................................24
3.2.4. Field Parsing ......................................25
3.2.5. Field Limits .......................................26
3.2.6. Field Value Components .............................27
3.3. Message Body ..............................................28
3.3.1. Transfer-Encoding ..................................28
3.3.2. Content-Length .....................................30
3.3.3. Message Body Length ................................32
3.4. Handling Incomplete Messages ..............................34
3.5. Message Parsing Robustness ................................34
4. Transfer Codings ...............................................35
4.1. Chunked Transfer Coding ...................................36
4.1.1. Chunk Extensions ...................................36
4.1.2. Chunked Trailer Part ...............................37
4.1.3. Decoding Chunked ...................................38
4.2. Compression Codings .......................................38
4.2.1. Compress Coding ....................................38
4.2.2. Deflate Coding .....................................38
4.2.3. Gzip Coding ........................................39
4.3. TE ........................................................39
4.4. Trailer ...................................................40
5. Message Routing ................................................40
5.1. Identifying a Target Resource .............................40
5.2. Connecting Inbound ........................................41
5.3. Request Target ............................................41
5.3.1. origin-form ........................................42
5.3.2. absolute-form ......................................42
5.3.3. authority-form .....................................43
5.3.4. asterisk-form ......................................43
5.4. Host ......................................................44
5.5. Effective Request URI .....................................45
5.6. Associating a Response to a Request .......................46
5.7. Message Forwarding ........................................47
5.7.1. Via ................................................47
5.7.2. Transformations ....................................49
6. Connection Management ..........................................50
6.1. Connection ................................................51
6.2. Establishment .............................................52
6.3. Persistence ...............................................52
6.3.1. Retrying Requests ..................................53
6.3.2. Pipelining .........................................54
6.4. Concurrency ...............................................55
6.5. Failures and Timeouts .....................................55
6.6. Tear-down .................................................56
6.7. Upgrade ...................................................57
7. ABNF List Extension: #rule .....................................59
8. IANA Considerations ............................................61
8.1. Header Field Registration .................................61
8.2. URI Scheme Registration ...................................62
8.3. Internet Media Type Registration ..........................62
8.3.1. Internet Media Type message/http ...................62
8.3.2. Internet Media Type application/http ...............63
8.4. Transfer Coding Registry ..................................64
8.4.1. Procedure ..........................................65
8.4.2. Registration .......................................65
8.5. Content Coding Registration ...............................66
8.6. Upgrade Token Registry ....................................66
8.6.1. Procedure ..........................................66
8.6.2. Upgrade Token Registration .........................67
9. Security Considerations ........................................67
9.1. Establishing Authority ....................................67
9.2. Risks of Intermediaries ...................................68
9.3. Attacks via Protocol Element Length .......................69
9.4. Response Splitting ........................................69
9.5. Request Smuggling .........................................70
9.6. Message Integrity .........................................70
9.7. Message Confidentiality ...................................71
9.8. Privacy of Server Log Information .........................71
10. Acknowledgments ...............................................72
11. References ....................................................74
11.1. Normative References .....................................74
11.2. Informative References ...................................75
Appendix A. HTTP Version History ..................................78
A.1. Changes from HTTP/1.0 ....................................78
A.1.1. Multihomed Web Servers ............................78
A.1.2. Keep-Alive Connections ............................79
A.1.3. Introduction of Transfer-Encoding .................79
A.2. Changes from RFC 2616 ....................................80
Appendix B. Collected ABNF ........................................82
Index .............................................................85
8. IANA Considerations ............................................61
8.1. Header Field Registration .................................61
8.2. URI Scheme Registration ...................................62
8.3. Internet Media Type Registration ..........................62
8.3.1. Internet Media Type message/http ...................62
8.3.2. Internet Media Type application/http ...............63
8.4. Transfer Coding Registry ..................................64
8.4.1. Procedure ..........................................65
8.4.2. Registration .......................................65
8.5. Content Coding Registration ...............................66
8.6. Upgrade Token Registry ....................................66
8.6.1. Procedure ..........................................66
8.6.2. Upgrade Token Registration .........................67
9. Security Considerations ........................................67
9.1. Establishing Authority ....................................67
9.2. Risks of Intermediaries ...................................68
9.3. Attacks via Protocol Element Length .......................69
9.4. Response Splitting ........................................69
9.5. Request Smuggling .........................................70
9.6. Message Integrity .........................................70
9.7. Message Confidentiality ...................................71
9.8. Privacy of Server Log Information .........................71
10. Acknowledgments ...............................................72
11. References ....................................................74
11.1. Normative References .....................................74
11.2. Informative References ...................................75
Appendix A. HTTP Version History ..................................78
A.1. Changes from HTTP/1.0 ....................................78
A.1.1. Multihomed Web Servers ............................78
A.1.2. Keep-Alive Connections ............................79
A.1.3. Introduction of Transfer-Encoding .................79
A.2. Changes from RFC 2616 ....................................80
Appendix B. Collected ABNF ........................................82
Index .............................................................85
The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document is the first in a series of documents that collectively form the HTTP/1.1 specification:
超文本传输协议（HTTP）是一种无状态的应用程序级请求/响应协议，它使用可扩展语义和自描述消息有效负载与基于网络的超文本信息系统进行灵活交互。本文档是共同构成HTTP/1.1规范的一系列文档中的第一个：
1. "Message Syntax and Routing" (this document)
1. “消息语法和路由”（本文档）
2. "Semantics and Content" [RFC7231]
2. “语义和内容”[RFC7231]
3. "Conditional Requests" [RFC7232]
3. “有条件请求”[RFC7232]
4. "Range Requests" [RFC7233]
4. “范围请求”[RFC7233]
5. "Caching" [RFC7234]
5. “缓存”[RFC7234]
6. "Authentication" [RFC7235]
6. “身份验证”[RFC7235]
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in RFC 2817, and defines the "https" URI scheme that was described informally in RFC 2818.
此HTTP/1.1规范淘汰了RFC 2616和RFC 2145（在HTTP版本控制上）。本规范还更新了先前在RFC 2817中定义的使用CONNECT建立隧道，并定义了RFC 2818中非正式描述的“https”URI方案。
HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.
HTTP是信息系统的通用接口协议。它旨在通过向客户机提供独立于所提供资源类型的统一接口来隐藏服务如何实现的细节。同样，服务器不需要知道每个客户端的用途：HTTP请求可以单独考虑，而不是与特定类型的客户端或预定的应用程序步骤序列相关联。结果是一个协议可以在许多不同的环境中有效地使用，并且实现可以随着时间的推移独立地发展。
HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.
HTTP还被设计为一种中介协议，用于在非HTTP信息系统之间转换通信。HTTP代理和网关可以通过将其不同的协议转换为超文本格式来提供对替代信息服务的访问，该超文本格式可由客户端以与HTTP服务相同的方式查看和操作。
One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions
这种灵活性的一个结果是协议不能根据接口后面发生的事情来定义。相反，我们仅限于定义通信语法、接收通信的意图以及接收者的预期行为。如果孤立地考虑通信，则成功的操作
ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
应该反映在服务器提供的可观察接口的相应更改中。然而，由于多个客户机可能并行运行，并且可能出于不同的目的，因此我们不能要求在单个响应的范围之外可以观察到这些变化。
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.
本文档描述了HTTP中使用或引用的体系结构元素，定义了“HTTP”和“https”URI方案，描述了总体网络操作和连接管理，并定义了HTTP消息帧和转发要求。我们的目标是定义独立于消息语义的HTTP消息处理所需的所有机制，从而定义消息解析器和消息转发中介的完整需求集。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
本规范使用[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), DIGIT (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（CR LF）、CTL（控件）、DIGIT（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、HTAB（水平制表符）、LF（换行符）、OCTET（任意8位数据序列）、SP（空格）和VCHAR（任意可见）[USASCII]字符）。
As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.
按照惯例，以“obs-”为前缀的ABNF规则名称表示出于历史原因出现的“过时”语法规则。
HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.
HTTP是为万维网（WWW）体系结构创建的，并随着时间的推移不断发展，以支持全球超文本系统的可伸缩性需求。这种体系结构的大部分反映在用于定义HTTP的术语和语法产品中。
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是一种无状态请求/响应协议，通过在可靠的传输层或会话层“连接”（第6节）上交换消息（第3节）进行操作。HTTP“客户端”是一个程序，它建立到服务器的连接，以发送一个或多个HTTP请求。HTTP“服务器”是一个程序，它接受连接，以便通过发送HTTP响应为HTTP请求提供服务。
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.
术语“客户端”和“服务器”仅指这些程序为特定连接执行的角色。同一程序可能在某些连接上充当客户端，在其他连接上充当服务器。术语“用户代理”是指发起请求的各种客户端程序，包括（但不限于）浏览器、爬行器（基于web的机器人）、命令行工具、自定义应用程序和移动应用程序。术语“源服务器”是指可以为给定目标资源发起权威响应的程序。术语“发送方”和“接收方”分别指发送或接收给定消息的任何实现。
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依赖统一资源标识符（URI）标准[RFC3986]来指示目标资源（第5.1节）和资源之间的关系。消息以类似于Internet邮件[RFC5322]和多用途Internet邮件扩展（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标识的某些资源。在最简单的情况下，这可以通过用户代理（UA）和源服务器（O）之间的单个双向连接（==）来实现。
request >
UA ======================================= O
< response
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).
客户端以请求消息的形式向服务器发送HTTP请求，从包含方法、URI和协议版本（第3.1.1节）的请求行开始，然后是包含请求修饰符、客户端信息和表示元数据（第3.2节）的头字段，这是一条空行，表示头部分的结尾，最后是包含有效负载主体的消息主体（如果有，请参见第3.3节）。
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响应消息来响应客户机的请求，每个消息以一个状态行开始，该状态行包括协议版本、成功或错误代码和文本原因短语（第3.1.2节），后面可能是包含服务器信息、资源元数据和表示元数据的头字段（第3.2节），一条空行，表示报头部分的结尾，最后是一条包含有效负载正文的消息正文（如有，第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上GET请求的典型消息交换（第4.3.1节[RFC7231]）”http://www.example.com/hello.txt":
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
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
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.
你好，世界！我的有效载荷包括一个尾部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
在考虑HTTP的设计时，很容易陷入这样的陷阱：所有用户代理都是通用浏览器，所有源服务器都是大型公共网站。事实并非如此。常见的HTTP用户代理包括各种形状和大小的家用电器、立体声音响、电子秤、固件更新脚本、命令行程序、移动应用程序和通信设备。同样，常见的HTTP源服务器包括家庭自动化
units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video-delivery platforms.
单元、可配置网络组件、办公机器、自动机器人、新闻提要、交通摄像头、广告选择器和视频传送平台。
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.
术语“用户代理”并不意味着在请求时存在直接与软件代理交互的人类用户。在许多情况下，用户代理被安装或配置为在后台运行，并保存其结果以供以后检查（或仅保存那些可能有趣或错误的结果的子集）。例如，爬行器通常被赋予一个起始URI，并被配置为在以超文本图的形式爬行Web时遵循某些行为。
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的实现多样性意味着并非所有的用户代理都可以向其用户提供交互式建议，或者为安全或隐私问题提供足够的警告。在本规范要求向用户报告错误的少数情况下，此类报告只能在错误控制台或日志文件中观察到是可以接受的。同样，在继续之前由用户确认自动操作的要求可以通过预先配置选择、运行时选项或简单地避免不安全操作来满足；如果用户已经做出选择，确认并不意味着任何特定的用户界面或正常处理的中断。
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允许使用中介通过连接链满足请求。HTTP中介有三种常见形式：代理、网关和隧道。在某些情况下，单个中介可能充当源服务器、代理、网关或隧道，根据每个请求的性质切换行为。
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
> > > >
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
上图显示了用户代理和源服务器之间的三个中介（A、B和C）。在整个链中传递的请求或响应消息将通过四个单独的连接。某些HTTP通信选项可能仅适用于具有最近的非隧道邻居的连接、仅适用于链的端点或链上的所有连接。虽然图表是线性的，但每个参与者可能同时参与多个通信。例如，在处理A的同时，B可能正在接收来自A以外的许多客户端的请求，和/或将请求转发到C以外的服务器
request. Likewise, later requests might be sent through a different path of connections, often based on dynamic configuration for load balancing.
要求类似地，以后的请求可能通过不同的连接路径发送，通常基于负载平衡的动态配置。
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.
术语“上游”和“下游”用于描述与信息流相关的方向要求：所有信息从上游流向下游。术语“入站”和“出站”用于描述与请求路由相关的方向性要求：“入站”表示指向源服务器，“出站”表示指向用户代理。
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.
“代理”是一种消息转发代理，客户端通常通过本地配置规则选择它来接收某些类型的绝对URI的请求，并尝试通过HTTP接口转换来满足这些请求。有些转换是最小的，例如对于“http”URI的代理请求，而其他请求可能需要转换到完全不同的应用程序级协议或从完全不同的应用程序级协议转换过来。为了安全、注释服务或共享缓存，代理通常用于通过公共中介对组织的HTTP请求进行分组。如第5.7.2节所述，一些代理设计用于在转发选定消息或有效负载时对其应用转换。
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.
“网关”（也称为“反向代理”）是一种中介，它充当出站连接的源服务器，但转换接收到的请求并将其转发到另一台或多台服务器。网关通常用于封装遗留或不受信任的信息服务，通过“加速器”缓存提高服务器性能，并支持跨多台计算机对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要求也适用于网关的出站通信。网关使用所需的任何协议与入站服务器通信，包括本规范范围之外的HTTP专用扩展。但是，希望与第三方HTTP服务器互操作的HTTP-to-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.
“隧道”充当两个连接之间的盲中继，而不改变消息。一旦激活，隧道就不会被视为HTTP通信的一方，尽管隧道可能是由HTTP请求启动的。当中继连接的两端都关闭时，隧道就不存在了。隧道用于通过中间层扩展虚拟连接，例如当使用传输层安全性（TLS，[RFC5246]）通过共享防火墙代理建立机密通信时。
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流量。网络中介体与中间人攻击无法区分（在协议级别），通常由于错误地违反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.
例如，“拦截代理”[RFC3040]（也称为“透明代理”[RFC1919]或“捕获门户”）与HTTP代理不同，因为它不是由客户端选择的。相反，拦截代理过滤或重定向传出的TCP端口80数据包（偶尔还有其他公共端口流量）。拦截代理通常出现在公共网络接入点上，作为在允许使用非本地Internet服务之前强制执行帐户订阅的一种手段，并在公司防火墙内强制执行网络使用策略。
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被定义为无状态协议，这意味着每个请求消息都可以独立理解。许多实现依赖于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.
“缓存”是先前响应消息的本地存储以及控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户机或服务器都可以使用缓存，尽管缓存在充当隧道时不能被服务器使用。
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.
缓存的效果是，如果链上的一个参与者具有适用于该请求的缓存响应，则请求/响应链会缩短。下面举例说明了如果B拥有O（通过C）对UA或a未缓存的请求的早期响应的缓存副本，则产生的链。
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
> >
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].
如果允许缓存存储响应消息的副本以用于应答后续请求，则响应是“可缓存的”。即使响应是可缓存的，客户机或源服务器也可能会对该缓存响应何时可用于特定请求设置其他约束。[RFC7234]第2节定义了缓存行为和可缓存响应的HTTP要求。
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.
在万维网和大型组织内部部署了各种各样的缓存体系结构和配置。这些包括用于节省跨洋带宽的代理缓存的国家层次结构、广播或多播缓存项的协作系统、用于离线或高延迟环境的预取缓存项存档，等等。
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需求被放置在发送者、接收者、客户端、服务器、用户代理、中介、源服务器、代理、网关或缓存上，这取决于需求约束的行为。当实现、资源所有者和协议元素注册超出单个通信范围时，会对它们提出附加（社会）要求。
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.
如果一个实现符合与它在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).
一致性包括协议元素的语法和语义。发送方不得生成传递发送方已知为虚假含义的协议元素。发送方不得生成与相应ABNF规则定义的语法不匹配的协议元素。在给定的消息中，发送方不得生成仅允许其他角色（即发送方不具有该消息的角色）的参与者生成的协议元素或语法备选方案。
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
解析接收到的协议元素时，接收方必须能够解析适用于接收方角色且与相应ABNF规则定义的语法匹配的合理长度的任何值。但是，请注意，可能无法解析某些接收到的协议元素。例如，中间人
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.
转发消息可能会将标头字段解析为通用字段名和字段值组件，但随后转发标头字段而无需在字段值内进行进一步解析。
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对其许多协议元素没有特定的长度限制，因为根据部署上下文和实现目的，合适的长度可能会有很大的差异。因此，发送方和接收方之间的互操作性取决于对每个协议元素的合理长度的共同期望。此外，在过去二十年的HTTP使用过程中，通常被理解为某些协议元素的合理长度已经发生了变化，预计未来还会继续变化。
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.
至少，收件人必须能够解析和处理协议元素长度，该长度至少与它为其他消息中的相同协议元素生成的值一样长。例如，发布对自己资源的很长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.
接收方必须根据本规范为其定义的语义（包括本规范的扩展）解释接收到的协议元素，除非接收方（通过经验或配置）确定发送方错误地实现了这些语义所暗示的内容。例如，如果对用户代理头字段的检查表明特定的实现版本在接收某些内容编码时失败，则源服务器可能会忽略接收到的接受编码头字段的内容。
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.
除非另有说明，否则接收方可尝试从无效构造恢复可用的协议元素。HTTP不定义特定的错误处理机制，除非它们对安全性有直接影响，因为协议的不同应用程序需要不同的错误处理策略。例如，Web浏览器可能希望从位置标头字段不根据ABNF解析的响应中透明地恢复，而系统控制客户端可能认为任何形式的错误恢复都是危险的。
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使用“<major><minor>”编号方案来指示协议的版本。本规范定义了版本“1.1”。协议版本作为一个整体表示发送方是否符合该版本的相应HTTP规范中列出的一组要求。
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版本字段指示。HTTP版本区分大小写。
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
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版本号由两个由“.”（句点或小数点）分隔的十进制数字组成。第一个数字（“主要版本”）表示HTTP消息传递语法，而第二个数字（“次要版本”）表示该主要版本中发送方遵守并能够理解以供将来通信的最高次要版本。次要版本宣传发送方的通信能力，即使发送方仅使用向后兼容的协议子集，从而让接收方知道更高级的功能可用于响应（由服务器）或将来的请求（由客户端）。
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消息的构造方式是，如果忽略所有较新的功能，则可以将其解释为有效的HTTP/1.0消息。本规范将收件人版本要求放在一些新功能上，以便一致的发件人仅使用兼容功能，直到通过配置或接收消息确定收件人支持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.
头字段的解释在同一主要HTTP版本的次要版本之间不会改变，尽管在没有此类字段的情况下收件人的默认行为可能会改变。除非另有规定，HTTP/1.1中定义的头字段是为所有版本的HTTP/1.x定义的。特别是，主机和连接头字段应该由所有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.
如果定义的语义允许不识别它们的收件人安全地忽略它们，则可以在不更改协议版本的情况下引入新的头字段。标题字段扩展性在第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消息的中介体（即除充当隧道的中介体以外的所有中介体）必须在转发的消息中发送自己的HTTP版本。换句话说，不允许他们盲目转发HTTP消息的第一行，而不确保该消息中的协议版本与该中介在消息的接收和发送方面都符合的版本相匹配。转发HTTP消息而不重写
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版本可能会导致通信错误。
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.
客户机应发送一个请求版本，该版本等于客户机符合的最高版本，并且其主版本不高于服务器支持的最高版本（如果已知）。客户机不得发送与其不一致的版本。
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.
服务器应发送一个响应版本，该版本等于服务器所符合的最高版本，且主版本小于或等于请求中接收的版本。服务器不得发送与其不一致的版本。如果出于任何原因，服务器希望拒绝客户端主要协议版本的服务，则可以发送505（不支持HTTP版本）响应。
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响应，例如，当客户端无法正确解析版本号时，或者当已知中介盲目转发HTTP版本时，即使它不符合协议的给定次要版本。除非由特定的客户端属性触发，例如当一个或多个请求头字段（例如，用户代理）唯一地匹配已知出错的客户端发送的值时，否则不应执行此类协议降级。
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版本控制设计的目的是，只有在引入不兼容的消息语法时，主数字才会增加，而只有当对协议所做的更改会增加消息语义或意味着发送方的附加功能时，次数字才会增加。然而，[RFC2068]和[RFC2616]之间引入的变更并未增加次要版本，本次修订明确避免了对协议的任何此类变更。
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
当接收到的HTTP消息的主版本号为收件人实现的版本号，但次版本号高于收件人实现的版本号时，收件人应将该消息视为收件人遵守的主版本中的最高次版本来处理。收件人可以假定
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.
具有较高次要版本的邮件在发送给尚未表示支持该较高版本的收件人时，具有足够的向后兼容性，可以由相同主要版本的任何实现安全地处理。
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.
统一资源标识符（URI）[RFC3986]在整个HTTP中用作识别资源的手段（RFC7231]第2节）。URI引用用于定位请求、指示重定向和定义关系。
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通用语法采用了“URI引用”、“绝对URI”、“相对部分”、“方案”、“权限”、“端口”、“主机”、“路径空”、“段”、“查询”和“片段”的定义。为可以包含非空路径组件的协议元素定义“绝对路径”规则。（此规则与RFC 3986的路径空规则（允许在引用中使用空路径）和路径绝对规则（不允许以“/”开头的路径）略有不同）为可以包含相对URI但不包含片段组件的协议元素定义了“部分URI”规则。
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>
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 ]
absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ]
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产品中指示该元素是否允许任何形式的引用（URI引用）、仅允许绝对形式的URI（绝对URI）、仅允许路径和可选查询组件，或上述组件的某种组合。除非另有说明，否则URI引用是相对于有效请求URI进行解析的（第5.5节）。
The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening for TCP ([RFC0793]) connections on a given port.
在此定义“http”URI方案是为了根据标识符与在给定端口上侦听TCP（[RFC0793]）连接的潜在http源服务器所管理的分层名称空间的关联来生成标识符。
http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
The origin server for an "http" URI is identified by the authority component, which includes a host identifier and optional TCP port ([RFC3986], Section 3.2.2). The hierarchical path component and optional query component serve as an identifier for a potential target resource within that origin server's name space. The optional fragment component allows for indirect identification of a secondary resource, independent of the URI scheme, as defined in Section 3.5 of [RFC3986].
“http”URI的源服务器由授权组件标识，其中包括主机标识符和可选TCP端口（[RFC3986]，第3.2.2节）。分层路径组件和可选查询组件用作源服务器名称空间内潜在目标资源的标识符。可选片段组件允许间接识别辅助资源，独立于URI方案，如[RFC3986]第3.5节所定义。
A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
发送方不得生成主机标识符为空的“http”URI。处理此类URI引用的收件人必须将其视为无效而拒绝。
If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address. If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default.
如果主机标识符作为IP地址提供，则源服务器是该IP地址处指定TCP端口上的侦听器（如果有）。如果主机是注册名称，则注册名称是一个间接标识符，可与名称解析服务（如DNS）一起使用，以查找该源服务器的地址。如果端口子组件为空或未给定，则默认为TCP端口80（WWW服务的保留端口）。
Note that the presence of a URI with a given authority component does not imply that there is always an HTTP server listening for connections on that host and port. Anyone can mint a URI. What the authority component determines is who has the right to respond authoritatively to requests that target the identified resource. The delegated nature of registered names and IP addresses creates a federated namespace, based on control over the indicated host and port, whether or not an HTTP server is present. See Section 9.1 for security considerations related to establishing authority.
请注意，具有给定权限组件的URI的存在并不意味着总有HTTP服务器在侦听该主机和端口上的连接。任何人都可以创建URI。授权组件确定的是谁有权以授权的方式响应针对已标识资源的请求。注册名称和IP地址的委托性质基于对指定主机和端口的控制（无论是否存在HTTP服务器）创建联合命名空间。有关建立权限的安全注意事项，请参见第9.1节。
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, and sending an HTTP request message (Section 3) containing the URI's identifying data (Section 5) to the server. If the server responds to that request with a non-interim
当在调用访问指示资源的上下文中使用“http”URI时，客户机可以通过将主机解析为IP地址、在指示端口上建立到该地址的TCP连接并向服务器发送包含URI的标识数据（第5节）的http请求消息（第3节）来尝试访问。如果服务器以非临时命令响应该请求
HTTP response message, as described in Section 6 of [RFC7231], then that response is considered an authoritative answer to the client's request.
HTTP响应消息，如[RFC7231]第6节所述，则该响应被视为对客户端请求的权威性响应。
Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources -- it is only the authoritative interface that is specific to TCP.
尽管HTTP独立于传输协议，“HTTP”方案特定于基于TCP的服务，因为名称委派过程依赖于TCP来建立权限。基于其他底层连接协议的HTTP服务可能会使用不同的URI方案进行标识，就像“https”方案（下面）用于需要端到端安全连接的资源一样。其他协议也可用于提供对“http”标识的资源的访问——它只是特定于TCP的权威接口。
The URI generic syntax for authority also includes a deprecated userinfo subcomponent ([RFC3986], Section 3.2.1) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.
授权的URI通用语法还包括一个不推荐使用的userinfo子组件（[RFC3986]，第3.2.1节），用于在URI中包含用户身份验证信息。有些实现使用userinfo组件进行身份验证信息的内部配置，例如在命令调用选项、配置文件或书签列表中，即使这种使用可能会公开用户标识符或密码。当在消息中生成“http”URI引用作为请求目标或标头字段值时，发送方不得生成userinfo子组件（及其“@”分隔符）。在使用从不受信任的源接收的“http”URI引用之前，收件人应解析userinfo并将其存在视为错误；它很可能被用来掩盖当局，以防网络钓鱼攻击。
The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections ([RFC5246]).
在此定义“https”URI方案是为了根据标识符与潜在HTTP源服务器（侦听TLS安全连接的给定TCP端口）（[RFC5246]）所管理的分层命名空间的关联来生成标识符。
All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that TCP port 443 is the default if the port subcomponent is empty or not given, and the user agent MUST ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending the first HTTP request.
上面列出的“http”方案的所有要求也是“https”方案的要求，但如果端口子组件为空或未给定，则TCP端口443是默认端口，并且用户代理必须确保通过使用端到端强加密保护其与源服务器的连接，在发送第一个HTTP请求之前。
https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for establishing authority. Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their
注意，“https”URI方案依赖于TLS和TCP来建立权限。通过“https”方案提供的资源与“http”方案没有共享标识，即使其
resource identifiers indicate the same authority (the same host listening to the same TCP port). They are distinct namespaces and are considered to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the Cookie protocol [RFC6265], can allow information set by one service to impact communication with other services within a matching group of host domains.
资源标识符表示相同的权限（同一主机侦听同一TCP端口）。它们是不同的名称空间，被认为是不同的源服务器。但是，定义为应用于整个主机域的HTTP扩展（如Cookie协议[RFC6265]）可以允许一个服务设置的信息影响与主机域匹配组内其他服务的通信。
The process for authoritative access to an "https" identified resource is defined in [RFC2818].
[RFC2818]中定义了权威访问“https”标识资源的过程。
Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to the algorithm defined in Section 6 of [RFC3986], using the defaults described above for each scheme.
由于“http”和“https”方案符合URI通用语法，因此根据[RFC3986]第6节中定义的算法，使用上述每个方案的默认值对此类URI进行规范化和比较。
If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent. When not being used in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections 2.1 and 2.2 of [RFC3986]).
如果端口等于方案的默认端口，则通常的形式是省略端口子组件。当不以绝对形式用作选项请求的请求目标时，空路径组件相当于绝对路径“/”，因此正常形式是提供路径“/”。scheme和host不区分大小写，通常以小写形式提供；以区分大小写的方式比较所有其他组件。除“保留”集中的字符外，其他字符相当于其编码的八位字节百分比：正常形式是不对其进行编码（见[RFC3986]第2.1节和第2.2节）。
For example, the following three URIs are equivalent:
例如，以下三个URI是等效的：
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in a format similar to the Internet Message Format [RFC5322]: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body.
所有HTTP/1.1消息都包含一个起始行，后跟一系列八位字节，格式类似于Internet消息格式[RFC5322]：零个或多个头字段（统称为“头”或“头部分”），一个空行表示头部分的结束，以及可选的消息正文。
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ]
HTTP消息=起始行*（标题字段CRLF）CRLF[消息正文]
The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length is read or the connection is closed.
解析HTTP消息的正常过程是将起始行读入结构，按字段名将每个头字段读入哈希表，直到空行为止，然后使用解析的数据确定是否需要消息体。如果已指示消息正文，则将其作为流读取，直到读取的八位字节数等于消息正文长度或连接关闭。
A recipient MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from the message, such as within a header field-value after message parsing has delineated the individual fields.
收件人必须将HTTP消息解析为编码为US-ASCII[USASCII]超集的八位字节序列。将HTTP消息解析为Unicode字符流，而不考虑特定编码，会由于字符串处理库处理包含八位字节LF（%x0A）的无效多字节字符序列的方式不同而造成安全漏洞。基于字符串的解析器只能在从消息中提取元素后安全地在协议元素中使用，例如在消息解析描述了各个字段后在头字段值中使用。
An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the sake of network efficiency, security checks, or payload transformations.
HTTP消息可以解析为一个流，用于增量处理或向下游转发。但是，收件人不能依赖于部分消息的增量传递，因为某些实现会为了网络效率、安全检查或负载转换而缓冲或延迟消息转发。
A sender MUST NOT send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated).
发件人不得在起始行和第一个标题字段之间发送空格。接收到起始行和第一个标头字段之间的空格的收件人必须拒绝邮件，因为邮件无效，或者在不进一步处理邮件的情况下使用前一行的空格（即，忽略整行，以及前面有空格的任何后续行，直到接收到格式正确的标头字段或标头部分终止）。
The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing.
请求中存在此类空白可能是试图欺骗服务器忽略该字段或将该字段后面的行作为新请求处理，如果请求链中的其他实现对同一消息的解释不同，这两种情况都可能导致安全漏洞。同样，某些客户端可能会忽略响应中存在此类空格，或者导致其他客户端停止解析。
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消息可以是从客户端到服务器的请求，也可以是从服务器到客户端的响应。从语法上讲，这两种类型的消息仅在起始行（请求行）或状态行（响应行）以及确定消息正文长度的算法（第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.
理论上，客户机可以接收请求，服务器可以接收响应，通过它们不同的起始行格式来区分它们，但在实践中，服务器实现为仅期望请求（响应被解释为未知或无效的请求方法），而客户机实现为仅期望响应。
start-line = request-line / status-line
start-line = request-line / status-line
A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), the protocol version, and ends with CRLF.
请求行以方法令牌开始，然后是单个空间（SP）、请求目标、另一个单个空间（SP）、协议版本，最后是CRLF。
request-line = method SP request-target SP HTTP-version CRLF
请求行=方法SP请求目标SP HTTP版本CRLF
The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.
method令牌指示要在目标资源上执行的请求方法。请求方法区分大小写。
method = token
method = token
The request methods defined by this specification can be found in Section 4 of [RFC7231], along with information regarding the HTTP method registry and considerations for defining new methods.
本规范定义的请求方法可在[RFC7231]的第4节中找到，以及有关HTTP方法注册表的信息和定义新方法的注意事项。
The request-target identifies the target resource upon which to apply the request, as defined in Section 5.3.
请求目标标识应用请求的目标资源，如第5.3节所定义。
Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), since no whitespace is allowed in the three components. Unfortunately, some user agents fail to properly encode or exclude whitespace found in hypertext references, resulting in those disallowed characters being sent in a request-target.
收件人通常通过在空格上拆分来将请求行解析为其组件部分（请参见第3.5节），因为这三个组件中不允许有空格。不幸的是，一些用户代理无法正确编码或排除超文本引用中的空白，导致在请求目标中发送这些不允许的字符。
Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. A recipient SHOULD NOT attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately crafted to bypass security filters along the request chain.
无效请求行的收件人应响应400（错误请求）错误或301（永久移动）重定向，并正确编码请求目标。收件人不应尝试自动更正然后在不重定向的情况下处理请求，因为无效的请求行可能被故意设计为绕过请求链上的安全过滤器。
HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5. A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code. A server that receives a
HTTP没有对请求行的长度设置预定义的限制，如第2.5节所述。接收比其实现的任何方法都长的方法的服务器应使用501（未实现）状态代码进行响应。接收数据的服务器
request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of [RFC7231]).
比它希望解析的任何URI都长的请求目标必须以414（URI太长）状态代码响应（请参见[RFC7231]第6.5.12节）。
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
在实践中，发现了请求行长度的各种特殊限制。建议所有HTTP发送方和接收方至少支持8000个八位字节的请求行长度。
The first line of a response message is the status-line, consisting of the protocol version, a space (SP), the status code, another space, a possibly empty textual phrase describing the status code, and ending with CRLF.
响应消息的第一行是状态行，由协议版本、一个空格（SP）、状态代码、另一个空格、描述状态代码的可能为空的文本短语组成，并以CRLF结尾。
status-line = HTTP-version SP status-code SP reason-phrase CRLF
状态行=HTTP版本SP状态代码SP原因短语CRLF
The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined for that status code. See Section 6 of [RFC7231] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
status code元素是一个3位整数代码，描述服务器试图理解和满足客户机相应请求的结果。响应消息的其余部分将根据为该状态代码定义的语义进行解释。有关状态代码语义的信息，请参见[RFC7231]第6节，包括状态代码类别（由第一位数字表示）、本规范定义的状态代码、新状态代码定义的注意事项以及IANA注册表。
status-code = 3DIGIT
status-code = 3DIGIT
The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the reason-phrase content.
“原因短语”元素的存在只是为了提供与数字状态代码相关联的文本描述，这主要是出于对早期互联网应用程序协议的尊重，而早期互联网应用程序协议更常用于交互式文本客户端。客户机应该忽略原因短语内容。
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
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 ":" OWS field-value OWS
标题字段=字段名“：“OWS字段值OWS”
field-name = token
field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar = VCHAR / obs-text
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
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.
字段名标记将相应的字段值标记为具有该标题字段定义的语义。例如，[RFC7231]第7.1.1.2节将日期标题字段定义为包含其出现的消息的起始时间戳。
Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification and in many other specifications outside this document set.
标题字段是完全可扩展的：引入新字段名（每个字段可能定义新语义）没有限制，给定消息中使用的标题字段数量也没有限制。现有字段在本规范的每个部分以及本文档集之外的许多其他规范中都有定义。
New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.
可以定义新的标题字段，以便在收件人理解这些字段时，它们可以覆盖或增强以前定义的标题字段的解释，定义请求评估的先决条件，或细化响应的含义。
A proxy MUST forward unrecognized header fields unless the field-name is listed in the Connection header field (Section 6.1) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
代理必须转发无法识别的头字段，除非连接头字段（第6.1节）中列出了字段名，或者代理被专门配置为阻止或转换此类字段。其他收件人应忽略无法识别的标题字段。这些要求允许增强HTTP的功能，而无需事先更新已部署的中介。
All defined header fields ought to be registered with IANA in the "Message Headers" registry, as described in Section 8.3 of [RFC7231].
如[RFC7231]第8.3节所述，所有定义的标题字段都应在“消息标题”注册表中向IANA注册。
The order in which header fields with differing field names are received is not significant. However, it is good practice to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible. A server MUST NOT apply a request to the target resource until the entire request
接收具有不同字段名的标题字段的顺序并不重要。但是，最好先发送包含控制数据的头字段，例如请求上的主机和响应上的日期，以便实现可以尽早决定何时不处理消息。在完成整个请求之前，服务器不得将请求应用于目标资源
header section is received, since later header fields might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
接收到header部分，因为后面的header字段可能包括条件、身份验证凭据或故意误导会影响请求处理的重复的header字段。
A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
发件人不得在邮件中生成具有相同字段名的多个标题字段，除非该标题字段的整个字段值定义为逗号分隔列表[即#（值）]，或者标题字段是众所周知的异常（如下所述）。
A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.
收件人可以将具有相同字段名的多个标题字段组合成一个“字段名：字段值”对，而不改变消息的语义，方法是将每个后续字段值按顺序附加到组合字段值，并用逗号分隔。因此，具有相同字段名称的标题字段的接收顺序对于组合字段值的解释非常重要；转发邮件时，代理不得更改这些字段值的顺序。
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of [Kri2001] for details.)
注意：在实践中，“Set Cookie”头字段（[RFC6265]）经常在响应消息中多次出现，并且不使用列表语法，违反了上述对同名多个头字段的要求。由于不能将其合并到单个字段值中，收件人在处理标题字段时应将“Set Cookie”作为特例处理。（详见[2001]附录A.2.3。）
This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and BWS ("bad" whitespace).
本规范使用三条规则来表示线性空白的使用：OWS（可选空白）、RWS（必需空白）和BWS（“坏”空白）。
The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace is preferred to improve readability, a sender SHOULD generate the optional whitespace as a single SP; otherwise, a sender SHOULD NOT generate optional whitespace except as needed to white out invalid or unwanted protocol elements during in-place message filtering.
OWS规则用于可能出现零个或多个线性空格八位字节的情况。对于首选可选空白以提高可读性的协议元素，发送方应将可选空白作为单个SP生成；否则，发送方不应生成可选的空白，除非需要在就地消息筛选过程中消除无效或不需要的协议元素。
The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender SHOULD generate RWS as a single SP.
当至少需要一个线性空格八位字节来分隔字段标记时，使用RWS规则。发送方应将RWS作为单个SP生成。
The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender MUST NOT generate BWS in messages. A recipient MUST parse for such bad whitespace and remove it before interpreting the protocol element.
BWS规则用于语法仅出于历史原因允许可选空白的情况。发件人不得在邮件中生成BWS。在解释协议元素之前，接收者必须解析此类错误的空白并将其删除。
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
Messages are parsed using a generic algorithm, independent of the individual header field names. The contents within a given field value are not parsed until a later stage of message interpretation (usually after the message's entire header section has been processed). Consequently, this specification does not use ABNF rules to define each "Field-Name: Field Value" pair, as was done in previous editions. Instead, this specification uses ABNF rules that are named according to each registered field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value has been extracted from the header section by a generic field parser).
消息使用通用算法进行解析，独立于单个头字段名称。在消息解释的后期阶段（通常在消息的整个标头部分处理完毕之后），才会解析给定字段值中的内容。因此，本规范不使用ABNF规则来定义每个“字段名：字段值”对，就像在以前的版本中所做的那样。相反，本规范使用根据每个注册字段名命名的ABNF规则，其中该规则定义该字段对应字段值的有效语法（即，在通用字段解析器从标题部分提取字段值之后）。
No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request). A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.
标题字段名和冒号之间不允许有空格。在过去，处理此类空白的差异导致了请求路由和响应处理中的安全漏洞。服务器必须拒绝任何接收到的请求消息，该消息包含头字段名和冒号之间的空格，响应代码为400（错误请求）。在将消息转发到下游之前，代理必须删除响应消息中的任何此类空白。
A field value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field-value is preferred for consistent readability by humans. The field value does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet of the field value ought to be excluded by parsers when extracting the field value from a header field.
字段值的前面和/或后面可能有可选的空白（OWS）；为确保一致的可读性，最好在字段值之前使用单个SP。字段值不包括任何前导或尾随空格：当从标头字段提取字段值时，解析器应排除字段值的第一个非空格八位组之前或最后一个非空格八位组之后出现的OWS。
Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 8.3.1). A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type.
历史上，HTTP头字段值可以通过在每一额外行前面至少加一个空格或水平选项卡（obs折叠）扩展到多行。除消息/http媒体类型（第8.3.1节）外，本规范不推荐此类行折叠。发送方不得生成包含行折叠的消息（即，包含与obs折叠规则匹配的任何字段值），除非该消息用于在消息/http媒体类型中打包。
A server that receives an obs-fold in a request message that is not within a message/http container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.
在不在消息/http容器内的请求消息中接收obs折叠的服务器必须通过发送400（错误请求）拒绝该消息，最好使用解释过时的行折叠是不可接受的表示，或者在解释字段值或向下游转发消息之前，用一个或多个SP八位字节替换每个接收到的obs折叠。
A proxy or gateway that receives an obs-fold in a response message that is not within a message/http container MUST either discard the message and replace it with a 502 (Bad Gateway) response, preferably with a representation explaining that unacceptable line folding was received, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.
在不在消息/http容器内的响应消息中接收obs折叠的代理或网关必须丢弃该消息并将其替换为502（坏网关）响应，最好使用解释接收到不可接受的行折叠的表示，或者在解释字段值或向下游转发消息之前，用一个或多个SP八位字节替换每个接收到的obs折叠。
A user agent that receives an obs-fold in a response message that is not within a message/http container MUST replace each received obs-fold with one or more SP octets prior to interpreting the field value.
在不在消息/http容器内的响应消息中接收obs折叠的用户代理必须在解释字段值之前，将每个接收到的obs折叠替换为一个或多个SP八位字节。
Historically, HTTP has allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset [USASCII]. Newly defined header fields SHOULD limit their field values to US-ASCII octets. A recipient SHOULD treat other octets in field content (obs-text) as opaque data.
历史上，HTTP允许字段内容包含ISO-8859-1字符集[ISO-8859-1]中的文本，仅通过使用[RFC2047]编码支持其他字符集。实际上，大多数HTTP头字段值仅使用US-ASCII字符集[USASCII]的子集。新定义的标题字段应将其字段值限制为US-ASCII八位字节。收件人应将字段内容（obs文本）中的其他八位字节视为不透明数据。
HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5. Various ad hoc limitations on individual header field length are found in practice, often depending on the specific field semantics.
HTTP没有对每个标头字段的长度或整个标头部分的长度设置预定义的限制，如第2.5节所述。实践中发现，对单个报头字段长度的各种特殊限制，通常取决于特定的字段语义。
A server that receives a request header field, or set of fields, larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 9.5).
接收到大于其希望处理的请求标头字段或字段集的服务器必须使用适当的4xx（客户端错误）状态代码进行响应。忽略此类头字段会增加服务器对请求走私攻击的漏洞（第9.5节）。
A client MAY discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
如果字段语义使得在不改变消息帧或响应语义的情况下可以安全地忽略丢弃的值，则客户端可以丢弃或截断接收到的大于客户端希望处理的报头字段。
Most HTTP header field values are defined using common syntax components (token, quoted-string, and comment) separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
大多数HTTP头字段值是使用公共语法组件（标记、带引号的字符串和注释）定义的，这些组件由空格或特定的分隔字符分隔。分隔符是从令牌中不允许的US-ASCII可视字符集中选择的（DQUOTE和“（），/：；<=>？@[\]{}”）。
token = 1*tchar
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters
A string of text is parsed as a single value if it is quoted using double-quote marks.
如果使用双引号将文本字符串引用，则将其解析为单个值。
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition.
通过用括号括住注释文本，注释可以包含在某些HTTP头字段中。仅允许在包含“注释”的字段中使用注释作为其字段值定义的一部分。
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. Recipients that process the value of a quoted-string MUST handle a quoted-pair as if it were replaced by the octet following the backslash.
反斜杠八位元（\）可以用作引用字符串和注释构造中的单个八位元引用机制。处理带引号字符串的值的收件人必须处理带引号的字符串对，就像它被反斜杠后面的八位字节替换一样。
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that string. A sender SHOULD NOT generate a quoted-pair in a comment except where necessary to quote parentheses ["(" and ")"] and backslash octets occurring within that comment.
发送方不应在带引号的字符串中生成带引号的对，除非有必要在该字符串中引用DQUOTE和反斜杠八位字节。发件人不应在注释中生成带引号的对，除非必要时引用括号[“（“and”）”]和注释中出现的反斜杠八位字节。
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消息的消息体（如果有）用于承载该请求或响应的有效负载体。如第3.3.1节所述，除非已应用传输编码，否则消息正文与有效载荷正文相同。
message-body = *OCTET
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.
请求中存在消息体由内容长度或传输编码头字段发出信号。请求消息框架独立于方法语义，即使该方法没有定义消息体的任何用途。
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节）。对头部请求方法的响应（RFC7231的第4.3.2节）从不包含消息正文，因为相关的响应头部字段（例如，传输编码、内容长度等）如果存在，则仅指示在获得请求方法的情况下它们的值（RFC7231的第4.3.1节）。对连接请求方法（RFC7231第4.3.6节）的2xx（成功）响应切换到隧道模式，而不是具有消息正文。所有1xx（信息）、204（无内容）和304（未修改）响应均不包含消息正文。所有其他响应都包含消息正文，尽管正文的长度可能为零。
The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in Section 4.
传输编码头字段列出与已（或将）应用于有效负载正文以形成消息正文的传输编码序列相对应的传输编码名称。第4节定义了转移编码。
Transfer-Encoding = 1#transfer-coding
传输编码=1#传输编码
Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport of binary data over a 7-bit transport service ([RFC2045], Section 6). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only applied for transport efficiency or security from those that are characteristics of the selected resource.
传输编码类似于MIME的内容传输编码字段，该字段旨在通过7位传输服务（RFC2045，第6节）安全传输二进制数据。但是，对于8位干净传输协议，安全传输有不同的重点。在HTTP的情况下，传输编码主要用于准确地界定动态生成的有效负载，并将仅用于传输效率或安全性的有效负载编码与作为所选资源特征的有效负载编码区分开来。
A recipient MUST be able to parse the chunked transfer coding (Section 4.1) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer coding other than chunked is applied to a request payload body, the sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection.
接收者必须能够解析分块传输编码（第4.1节），因为在事先不知道有效负载主体大小的情况下，分块传输编码在构建消息时起着至关重要的作用。发件人不得对邮件正文应用分块多次（即，不允许对已分块的邮件进行分块）。如果对请求有效负载主体应用了除chunked之外的任何传输编码，则发送方必须将chunked应用为最终传输编码，以确保消息正确帧化。如果对响应有效负载主体应用了chunked以外的任何传输编码，则发送方必须将chunked应用为最终传输编码，或者通过关闭连接来终止消息。
For example,
例如
Transfer-Encoding: gzip, chunked
传输编码：gzip，分块
indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while forming the message body.
指示有效负载正文已使用gzip编码进行压缩，然后在形成消息正文时使用分块编码进行分块。
Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response chain MAY decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters can be provided by other header fields not defined by this specification.
与内容编码（RFC7231第3.1.2.1节）不同，传输编码是消息的属性，而不是表示的属性，请求/响应链上的任何收件人都可以解码接收到的传输编码或对消息体应用额外的传输编码，假设对传输编码字段值进行了相应的更改。有关编码参数的附加信息可由本规范未定义的其他标题字段提供。
Transfer-Encoding MAY be sent in a response to a HEAD request or in a 304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
传输编码可以在对HEAD请求的响应中发送，也可以在对GET请求的304（未修改）响应（RFC7232的第4.1节）中发送，两者都不包括消息体，以指示如果请求是无条件GET，则源服务器将对消息体应用传输编码。但是，不需要此指示，因为响应链上的任何收件人（包括源服务器）都可以在不需要时删除传输编码。
A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Transfer-Encoding header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [RFC7231]).
服务器不得在状态代码为1xx（信息性）或204（无内容）的任何响应中发送传输编码头字段。服务器不得在对连接请求（RFC7231）的任何2xx（成功）响应中发送传输编码头字段（第4.3.6节）。
Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload. A client MUST NOT send a request containing Transfer-Encoding unless it knows the
HTTP/1.1中添加了传输编码。通常认为，仅宣传HTTP/1.0支持的实现不会理解如何处理传输编码的有效负载。客户机不得发送包含传输编码的请求，除非它知道
server will handle HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response. A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
服务器将处理HTTP/1.1（或更高版本）请求；此类知识可能以特定用户配置的形式存在，或者通过记住先前收到的响应的版本存在。除非相应的请求指示HTTP/1.1（或更高版本），否则服务器不得发送包含传输编码的响应。
A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).
接收到传输编码不清楚的请求消息的服务器应使用501（未实现）进行响应。
When a message does not have a Transfer-Encoding header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (Section 3 of [RFC7231]).
当消息没有传输编码报头字段时，内容长度报头字段可以提供潜在有效负载正文的预期大小（十进制八位字节数）。对于包含有效负载正文的消息，内容长度字段值提供确定正文（和消息）结束位置所需的帧信息。对于不包含有效负载正文的消息，内容长度表示所选表示的大小（RFC7231第3节）。
Content-Length = 1*DIGIT
Content-Length = 1*DIGIT
An example is
例如
Content-Length: 3495
内容长度：3495
A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.
发件人不得在包含传输编码标头字段的任何邮件中发送内容长度标头字段。
A user agent SHOULD send a Content-Length in a request message when no Transfer-Encoding is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body.
当未发送传输编码时，用户代理应在请求消息中发送内容长度，并且请求方法定义了封闭有效负载主体的含义。例如，内容长度头字段通常在POST请求中发送，即使该值为0（表示空的有效负载正文）。当请求消息不包含有效负载主体并且方法语义不预期这样的主体时，用户代理不应该发送内容长度头字段。
A server MAY send a Content-Length header field in a response to a HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent in the payload body of a response if the same request had used the GET method.
服务器可以在响应头请求时发送内容长度头字段（RFC7231第4.3.2节）；服务器不得在此类响应中发送内容长度，除非其字段值等于在同一请求使用GET方法时在响应的有效负载正文中发送的十进制八位字节数。
A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request (Section 4.1 of [RFC7232]); a server MUST NOT send Content-Length in such a response
服务器可以在304（未修改）响应中向条件GET请求发送内容长度头字段（RFC7232第4.1节）；服务器不得在此类响应中发送内容长度
unless its field-value equals the decimal number of octets that would have been sent in the payload body of a 200 (OK) response to the same request.
除非其字段值等于对同一请求的200（OK）响应的有效负载正文中发送的十进制八位字节数。
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [RFC7231]).
服务器不得在状态代码为1xx（信息性）或204（无内容）的任何响应中发送内容长度标题字段。服务器不得在对连接请求（RFC7231）的任何2xx（成功）响应中发送内容长度头字段（第4.3.6节）。
Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server SHOULD send a Content-Length header field when the payload body size is known prior to sending the complete header section. This will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse the connection for additional requests.
除了上面定义的情况外，在没有传输编码的情况下，当在发送完整的报头部分之前已知有效负载正文大小时，源服务器应该发送内容长度报头字段。这将允许下游接收者测量传输进度，知道接收到的消息何时完成，并有可能为其他请求重用连接。
Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of a payload, a recipient MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (Section 9.3).
任何大于或等于零的内容长度字段值都是有效的。由于对有效负载的长度没有预定义的限制，因此收件人必须预测可能较大的十进制数字，并防止由于整数转换溢出而导致的解析错误（第9.3节）。
If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, then the recipient MUST either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing that decimal value prior to determining the message body length or forwarding the message.
如果收到的消息包含多个内容长度标题字段，其字段值由相同的十进制值组成，或者包含单个内容长度标题字段，其字段值包含相同的十进制值列表（例如，“内容长度：42，42”），指示上游消息处理器已生成或组合重复的内容长度标头字段，然后，在确定邮件正文长度或转发邮件之前，收件人必须将邮件视为无效而拒绝，或将重复的字段值替换为包含该十进制值的单个有效内容长度字段。
Note: HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional field used only within the "message/external-body" media-type.
注意：HTTP对消息帧内容长度的使用与MIME中相同字段的使用有很大不同，后者是一个可选字段，仅在“message/external body”媒体类型中使用。
The length of a message body is determined by one of the following (in order of precedence):
消息正文的长度由以下内容之一决定（按优先顺序排列）：
1. Any response to a HEAD request and any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body.
1. 对HEAD请求的任何响应以及带有1xx（信息性）、204（无内容）或304（未修改）状态代码的任何响应始终由标头字段后的第一个空行终止，而与消息中存在的标头字段无关，因此不能包含消息正文。
2. Any 2xx (Successful) response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes the header fields. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in such a message.
2. 对连接请求的任何2xx（成功）响应都意味着连接将在结束标头字段的空行之后立即成为隧道。客户端必须忽略在此类消息中接收到的任何内容长度或传输编码头字段。
3. If a Transfer-Encoding header field is present and the chunked transfer coding (Section 4.1) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer coding indicates the data is complete.
3. 如果存在传输编码头字段，且分块传输编码（第4.1节）是最终编码，则通过读取和解码分块数据来确定消息正文长度，直到传输编码指示数据完成。
If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
如果响应中存在传输编码头字段，且分块传输编码不是最终编码，则通过读取连接直到服务器关闭连接来确定消息正文长度。如果请求中存在传输编码头字段，且分块传输编码不是最终编码，则无法可靠地确定消息正文长度；服务器必须响应400（错误请求）状态代码，然后关闭连接。
If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.
如果同时使用传输编码和内容长度标题字段接收消息，则传输编码将覆盖内容长度。此类消息可能表示有人试图执行请求走私（第9.5节）或响应拆分（第9.4节），应将其视为错误处理。发送方必须先删除接收的内容长度字段，然后才能将此类消息转发到下游。
4. If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error. If this is a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad
4. 如果接收到的消息没有传输编码，并且多个内容长度头字段具有不同的字段值，或者单个内容长度头字段具有无效值，则消息帧无效，收件人必须将其视为不可恢复的错误。如果这是一条请求消息，服务器必须响应400（错误请求）状态代码，然后关闭连接。如果这是代理收到的响应消息，则代理必须关闭与服务器的连接，放弃收到的响应，并发送502（错误消息）
Gateway) response to the client. If this is a response message received by a user agent, the user agent MUST close the connection to the server and discard the received response.
网关）对客户端的响应。如果这是用户代理收到的响应消息，则用户代理必须关闭与服务器的连接并放弃收到的响应。
5. If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.
5. 如果存在没有传输编码的有效内容长度标头字段，则其十进制值以八位字节定义预期的消息正文长度。如果发送方在接收到所指示的八位字节之前关闭连接或接收者超时，接收方必须考虑消息不完整并关闭连接。
6. If this is a request message and none of the above are true, then the message body length is zero (no message body is present).
6. 如果这是一条请求消息，且上述各项均不正确，则消息正文长度为零（不存在任何消息正文）。
7. Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.
7. 否则，这是一条没有声明消息正文长度的响应消息，因此消息正文长度由服务器关闭连接之前接收的八位字节数决定。
Since there is no way to distinguish a successfully completed, close-delimited message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0.
由于无法区分成功完成的、关闭分隔的消息和因网络故障而中断的部分接收的消息，因此服务器应尽可能生成编码或长度分隔的消息。关闭定界特性的存在主要是为了向后兼容HTTP/1.0。
A server MAY reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).
服务器可以通过使用411（所需长度）进行响应来拒绝包含消息正文但不包含内容长度的请求。
Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body SHOULD use a valid Content-Length header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing services respond to chunked with a 411 (Length Required) status code even though they understand the chunked transfer coding. This is typically because such services are implemented via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire request before processing.
除非应用了分块以外的传输编码，否则如果消息正文长度事先已知，则发送包含消息正文的请求的客户端应使用有效的内容长度头字段，而不是分块传输编码，因为某些现有服务对分块的响应为411（所需长度）状态代码，即使他们理解分块传输编码。这通常是因为此类服务是通过网关实现的，在调用之前需要内容长度，并且服务器无法或不愿意在处理之前缓冲整个请求。
A user agent that sends a request containing a message body MUST send a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
发送包含消息正文的请求的用户代理如果不知道服务器将处理HTTP/1.1（或更高版本）请求，则必须发送有效的内容长度头字段；此类知识可以是特定用户配置的形式，或者通过记住先前接收到的响应的版本。
If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that
如果已完全接收到对连接上最后一个请求的最终响应，并且仍有其他数据需要读取，则用户代理可能会丢弃其余数据，或者尝试确定是否存在此问题
data belongs as part of the prior response body, which might be the case if the prior message's Content-Length value is incorrect. A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.
数据属于先前响应正文的一部分，如果先前消息的内容长度值不正确，则可能会出现这种情况。客户端不得将此类额外数据作为单独的响应进行处理、缓存或转发，因为此类行为容易受到缓存中毒的影响。
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].
接收到不完整响应消息的客户端必须将该消息记录为不完整消息，该消息可能发生在连接过早关闭或假定的分块传输编码解码失败时。[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.
如果响应在报头部分的中间终止（在接收到空行之前）并且状态代码可能依赖于报头字段来传递响应的全部含义，那么客户端不能假设已经传送了含义；客户端可能需要重复该请求以确定下一步要采取的操作。
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.
如果没有收到终止编码的零大小块，则使用分块传输编码的消息正文是不完整的。如果接收的消息正文大小（以八位字节为单位）小于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用户代理实现可能会在POST请求后发送额外的CRLF，作为一些早期服务器应用程序的解决方法，这些应用程序无法读取未以行结尾终止的消息正文内容。HTTP/1.1用户代理不得在请求之前或之后添加额外的CRLF。如果需要以行结尾终止请求消息正文，则用户代理必须将终止的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.
出于健壮性的考虑，希望接收和解析请求行的服务器应该忽略至少一个在请求行之前接收的空行（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.
尽管起始行和标题字段的行终止符是序列CRLF，但收件人可以将单个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).
尽管请求行和状态行语法规则要求每个组件元素由单个SP八位字节分隔，但收件人可以改为解析以空格分隔的单词边界，并且除了CRLF终止符之外，将任何形式的空格视为SP分隔符，同时忽略前面或后面的空格；此类空白包括以下一个或多个八位字节：SP、HTAB、VT（%x0B）、FF（%x0C）或裸CR。但是，如果消息有多个接收者，且每个接收者都有自己独特的健壮性解释，则宽松解析可能会导致安全漏洞（见第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请求消息的内容时，除了上面列出的健壮性异常外，还接收到与HTTP消息语法不匹配的八位字节序列时，服务器应以400（错误请求）响应。
Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred.
传输编码名称用于指示已经、可以或可能需要应用于有效负载主体的编码转换，以确保通过网络的“安全传输”。这不同于内容编码，因为传输编码是消息的属性，而不是正在传输的表示的属性。
transfer-coding = "chunked" ; Section 4.1
/ "compress" ; Section 4.2.1
/ "deflate" ; Section 4.2.2
/ "gzip" ; Section 4.2.3
/ transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-coding = "chunked" ; Section 4.1
/ "compress" ; Section 4.2.1
/ "deflate" ; Section 4.2.2
/ "gzip" ; Section 4.2.3
/ transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair.
参数采用名称或名称=值对的形式。
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in Section 8.4. They are used in the TE (Section 4.3) and Transfer-Encoding (Section 3.3.1) header fields.
所有传输编码名称都不区分大小写，应在HTTP传输编码注册表中注册，如第8.4节所定义。它们用于TE（第4.3节）和传输编码（第3.3.1节）标题字段。
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使大小未知的内容流能够作为一系列长度分隔的缓冲区进行传输，这使发送方能够保留连接持久性，而接收方能够知道它何时收到了整个消息。
chunked-body = *chunk
last-chunk
trailer-part
CRLF
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=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
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.
区块大小字段是一个十六进制数字字符串，以八位字节表示区块数据的大小。当接收到块大小为零的块时，分块传输编码完成，可能后跟一个尾部，最后以空行终止。
A recipient MUST be able to parse and decode the chunked transfer coding.
收件人必须能够解析和解码分块传输编码。
The chunked encoding allows each chunk to include zero or more chunk extensions, immediately following the chunk-size, for the sake of supplying per-chunk metadata (such as a signature or hash), mid-message control information, or randomization of message body size.
分块编码允许每个分块包含零个或多个分块扩展，紧跟在分块大小之后，以便提供每个分块元数据（例如签名或散列）、中间消息控制信息或消息正文大小的随机化。
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token chunk-ext-val = token / quoted-string
chunk ext name=标记chunk ext val=标记/带引号的字符串
The chunked encoding is specific to each connection and is likely to be removed or recoded by each recipient (including intermediaries) before any higher-level application would have a chance to inspect the extensions. Hence, use of chunk extensions is generally limited
分块编码是特定于每个连接的，在任何更高级别的应用程序有机会检查扩展之前，每个收件人（包括中间人）可能会删除或重新编码该编码。因此，块扩展的使用通常是有限的
to specialized HTTP services such as "long polling" (where client and server can have shared expectations regarding the use of chunk extensions) or for padding within an end-to-end secured connection.
专门的HTTP服务，如“长轮询”（客户机和服务器可以对区块扩展的使用有共同的期望）或端到端安全连接中的填充。
A recipient MUST ignore unrecognized chunk extensions. A server ought to limit the total length of chunk extensions received in a request to an amount reasonable for the services provided, in the same way that it applies length limitations and timeouts for other parts of a message, and generate an appropriate 4xx (Client Error) response if that amount is exceeded.
收件人必须忽略无法识别的区块扩展。服务器应该将请求中接收的区块扩展的总长度限制在对所提供服务合理的范围内，就像它对消息的其他部分应用长度限制和超时一样，如果超过该范围，则生成适当的4xx（客户端错误）响应。
A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's header section.
尾部允许发送方在分块消息的末尾包含附加字段，以便提供在发送消息正文时动态生成的元数据，例如消息完整性检查、数字签名或后处理状态。拖车字段与标题字段相同，只是它们是在分块拖车中发送的，而不是消息的标题部分。
trailer-part = *( header-field CRLF )
trailer-part = *( header-field CRLF )
A sender MUST NOT generate a trailer that contains a field necessary for message framing (e.g., Transfer-Encoding and Content-Length), routing (e.g., Host), request modifiers (e.g., controls and conditionals in Section 5 of [RFC7231]), authentication (e.g., see [RFC7235] and [RFC6265]), response control data (e.g., see Section 7.1 of [RFC7231]), or determining how to process the payload (e.g., Content-Encoding, Content-Type, Content-Range, and Trailer).
发送方不得生成包含消息帧（如传输编码和内容长度）、路由（如主机）、请求修饰符（如[RFC7231]第5节中的控件和条件）、身份验证（如参见[RFC7235]和[RFC6265]）、响应控制数据（如参见[RFC7231]第7.1节）所需字段的预告，或确定如何处理有效负载（例如，内容编码、内容类型、内容范围和拖车）。
When a chunked message containing a non-empty trailer is received, the recipient MAY process the fields (aside from those forbidden above) as if they were appended to the message's header section. A recipient MUST ignore (or consider as an error) any fields that are forbidden to be sent in a trailer, since processing them as if they were present in the header section might bypass external security filters.
当接收到包含非空尾部的分块消息时，收件人可以处理字段（除了上面禁止的字段），就好像它们被附加到消息的标题部分一样。收件人必须忽略（或认为是一个错误）禁止在预告片中发送的任何字段，因为处理它们就像在头段中存在一样，可能会绕过外部安全过滤器。
Unless the request includes a TE header field indicating "trailers" is acceptable, as described in Section 4.3, a server SHOULD NOT generate trailer fields that it believes are necessary for the user agent to receive. Without a TE containing "trailers", the server ought to assume that the trailer fields might be silently discarded along the path to the user agent. This requirement allows intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering the entire response.
除非请求包含一个TE头字段，指示“拖车”是可接受的，如第4.3节所述，否则服务器不应生成其认为用户代理接收所需的拖车字段。如果TE不包含“拖车”，服务器应该假设拖车字段可能会沿着用户代理的路径被悄悄地丢弃。此要求允许中介将解块消息转发给HTTP/1.0收件人，而无需缓冲整个响应。
A process for decoding the chunked transfer coding can be represented in pseudo-code as:
用于解码分块传输编码的过程可以用伪码表示为：
length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to decoded-body
length := length + chunk-size
read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
if (trailer field is allowed to be sent in a trailer) {
append trailer field to existing header fields
}
read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields
length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to decoded-body
length := length + chunk-size
read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
if (trailer field is allowed to be sent in a trailer) {
append trailer field to existing header fields
}
read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields
The codings defined below can be used to compress the payload of a message.
下面定义的编码可用于压缩消息的有效负载。
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding [Welch] that is commonly produced by the UNIX file compression program "compress". A recipient SHOULD consider "x-compress" to be equivalent to "compress".
“压缩”编码是一种自适应Lempel-Ziv-Welch（LZW）编码[Welch]，通常由UNIX文件压缩程序“压缩”生成。收件人应考虑“X压缩”相当于“压缩”。
The "deflate" coding is a "zlib" data format [RFC1950] containing a "deflate" compressed data stream [RFC1951] that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
“deflate”编码是一种“zlib”数据格式[RFC1950]，其中包含一个“deflate”压缩数据流[RFC1951]，该压缩数据流使用Lempel-Ziv（LZ77）压缩算法和哈夫曼编码的组合。
Note: Some non-conformant implementations send the "deflate" compressed data without the zlib wrapper.
注意：一些非一致性实现在不使用zlib包装器的情况下发送“deflate”压缩数据。
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program [RFC1952]. A recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
“gzip”编码是一种LZ77编码，带有32位循环冗余校验（CRC），通常由gzip文件压缩程序[RFC1952]产生。收件人应考虑“X-GZIP”相当于“GZIP”。
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”头字段指示除了分块之外，客户端愿意接受哪些传输编码作为响应，以及客户端是否愿意接受分块传输编码中的尾部字段。
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节所述）和/或关键字“拖车”。客户端不得在TE中发送分块传输编码名称；对于HTTP/1.1收件人，分块始终是可接受的。
TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
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
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.
关键字“拖车”的存在表明客户愿意代表其自身和任何下游客户接受第4.1.2节定义的分块传输编码中的拖车字段。对于中间人的请求，这意味着：（a）所有下游客户都愿意接受转发响应中的尾部字段；或者，（b）中间人将尝试代表下游接收人缓冲响应。请注意，HTTP/1.1没有定义任何方法来限制分块响应的大小，以确保中介可以缓冲整个响应。
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
当可以接受多个传输编码时，客户可以使用不区分大小写的“q”参数（类似于内容协商字段中使用的q值，第节）按优先顺序对编码进行排序
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".
5.3.1 属于[RFC7231]）。秩值是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字段值为空或不存在TE字段，则将对唯一可接受的传输编码进行分块。始终可以接受没有传输编码的消息。
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报头字段仅适用于即时连接，TE的发送方还必须在连接报头字段内发送“TE”连接选项（第6.1节），以防止TE字段被不支持其语义的中介转发。
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.
当消息包含使用分块传输编码编码的消息正文，并且发送方希望在消息末尾以拖车字段的形式发送元数据时，发送方应在消息正文之前生成拖车头字段，以指示拖车中将出现哪些字段。这允许收件人在开始处理正文之前准备接收该元数据，这在邮件正在进行流式传输且收件人希望实时确认完整性检查时非常有用。
Trailer = 1#field-name
拖车=1#字段名称
HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain back to the client.
HTTP请求消息路由由每个客户端根据目标资源、客户端的代理配置以及入站连接的建立或重用来确定。相应的响应路由遵循相同的连接链返回到客户端。
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客户端依赖于与通用Web浏览器相同的资源标识机制和配置技术。
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
HTTP通信是由用户代理出于某种目的发起的。其目的是将[RFC7231]中定义的请求语义与应用这些语义的目标资源相结合。URI引用（第2.7节）通常用作
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).
“目标资源”的标识符，用户代理将其解析为其绝对形式，以获取“目标URI”。目标URI不包括引用的片段组件（如果有），因为片段标识符保留用于客户端处理（[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，客户机就需要确定是否需要网络请求来完成所需的语义，如果需要，那么该请求将被定向到何处。
If the client has a cache [RFC7234] and the request can be satisfied by it, then the request is usually directed there first.
如果客户机有一个缓存[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.
如果缓存未满足请求，则典型客户端将检查其配置，以确定是否使用代理来满足请求。代理配置依赖于实现，但通常基于URI前缀匹配、选择性权限匹配或两者，并且代理本身通常由“http”或“https”URI标识。如果代理适用，则客户端通过建立（或重用）到该代理的连接来连接入站。
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的方案），以直接连接到目标资源的授权。如何实现这一点取决于目标URI方案并由其相关规范定义，类似于本规范如何定义源服务器访问以解决“http”（第2.7.1节）和“https”（第2.7.2节）方案。
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.
一旦获得入站连接，客户端将发送一条HTTP请求消息（第3节），其中包含一个从目标URI派生的请求目标。请求目标有四种不同的格式，这取决于所请求的方法以及请求是否发送给代理。
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
The most common form of request-target is the origin-form.
请求目标的最常见形式是原始形式。
origin-form = absolute-path [ "?" query ]
原点形式=绝对路径[“？”查询]
When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 5.4.
当直接向源服务器发出请求时，除了连接或服务器范围的选项请求（如下所述），客户机必须仅发送目标URI的绝对路径和查询组件作为请求目标。如果目标URI的路径组件为空，则客户端必须在请求目标的原始表单中发送“/”作为路径。根据第5.4节的定义，还将发送主机标题字段。
For example, a client wishing to retrieve a representation of the resource identified as
例如，希望检索标识为的资源表示的客户端
http://www.example.org/where?q=now
http://www.example.org/where?q=now
directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the lines:
直接从源服务器打开（或重新使用）到主机“www.example.org”端口80的TCP连接，并发送以下行：
GET /where?q=now HTTP/1.1
Host: www.example.org
GET /where?q=now HTTP/1.1
Host: www.example.org
followed by the remainder of the request message.
然后是请求消息的其余部分。
When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send the target URI in absolute-form as the request-target.
当向代理发出请求时，除了连接或服务器范围的选项请求（如下所述），客户端必须以绝对形式发送目标URI作为请求目标。
absolute-form = absolute-URI
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in Section 5.7.
如果可能，将请求代理为有效缓存中的该请求提供服务，或者代表客户端向下一个入站代理服务器或直接向请求目标指示的源服务器发出相同的请求。第5.7节规定了此类“转发”信息的要求。
An example absolute-form of request-line would be:
请求行的绝对形式示例如下：
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
为了在将来的HTTP版本中允许所有请求转换为绝对形式，服务器必须在请求中接受绝对形式，即使HTTP/1.1客户端只在请求中向代理发送请求。
The authority-form of request-target is only used for CONNECT requests (Section 4.3.6 of [RFC7231]).
请求目标的授权形式仅用于连接请求（RFC7231第4.3.6节）。
authority-form = authority
authority-form = authority
When making a CONNECT request to establish a tunnel through one or more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
当通过一个或多个代理发出连接请求以建立隧道时，客户端必须仅发送目标URI的授权组件（不包括任何userinfo及其“@”分隔符）作为请求目标。例如
CONNECT www.example.com:80 HTTP/1.1
连接www.example.com:80 HTTP/1.1
The asterisk-form of request-target is only used for a server-wide OPTIONS request (Section 4.3.7 of [RFC7231]).
请求目标的星号形式仅用于服务器范围的选项请求（RFC7231的第4.3.7节）。
asterisk-form = "*"
星号形式=“*”
When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, the client MUST send only "*" (%x2A) as the request-target. For example,
当客户端希望为整个服务器请求选项时，而不是该服务器的特定命名资源，客户端必须只发送“*”（%x2A）作为请求目标。例如
OPTIONS * HTTP/1.1
选项*HTTP/1.1
If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of "*" when it forwards the request to the indicated origin server.
如果代理接收到具有绝对形式的请求目标的选项请求，其中URI具有空路径且没有查询组件，则请求链上的最后一个代理在将请求转发到指定的源服务器时必须发送“*”的请求目标。
For example, the request
例如，请求
OPTIONS http://www.example.org:8001 HTTP/1.1
OPTIONS http://www.example.org:8001 HTTP/1.1
would be forwarded by the final proxy as
将由最终代理作为
OPTIONS * HTTP/1.1
Host: www.example.org:8001
OPTIONS * HTTP/1.1
Host: www.example.org:8001
after connecting to port 8001 of host "www.example.org".
连接到主机“www.example.org”的端口8001后。
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.
请求中的“主机”标头字段提供来自目标URI的主机和端口信息，使源服务器能够在为单个IP地址上的多个主机名请求提供服务的同时区分资源。
Host = uri-host [ ":" port ] ; Section 2.7.1
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请求消息中发送主机头字段。如果目标URI包含权限组件，则客户端必须为主机发送与该权限组件相同的字段值，不包括任何userinfo子组件及其“@”分隔符（第2.7.1节）。如果目标URI缺少或未定义授权组件，则客户端必须发送一个带有空字段值的主机头字段。
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.
由于主机字段值是处理请求的关键信息，因此用户代理应生成主机作为请求行后面的第一个标头字段。
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
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请求中发送主机头字段，因为这允许主机信息通过可能未实现主机的古老HTTP/1.0代理转发。
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.
当代理接收到具有绝对形式的请求目标的请求时，代理必须忽略接收到的主机头字段（如果有），而是将其替换为请求目标的主机信息。转发此类请求的代理必须基于收到的请求目标生成新的主机字段值，而不是转发收到的主机字段值。
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.
由于主机头字段充当应用程序级路由机制，因此它经常成为恶意软件攻击共享缓存或将请求重定向到非预期服务器的目标。如果拦截代理依赖主机字段值将请求重定向到内部服务器，或用作共享缓存中的缓存密钥，而没有首先验证被拦截的连接是否以该主机的有效IP地址为目标，则该代理尤其容易受到攻击。
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请求消息，以及任何包含多个主机标头字段或具有无效字段值的主机标头字段的请求消息，服务器必须使用400（错误请求）状态代码进行响应。
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.
由于请求目标通常只包含用户代理的目标URI的一部分，因此服务器将预期目标重建为“有效的请求URI”，以正确地服务请求。此重构涉及服务器的本地配置和在请求目标、主机头字段和连接上下文中传递的信息。
For a user agent, the effective request URI is the target URI.
对于用户代理，有效的请求URI是目标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:
如果请求目标为绝对形式，则有效请求URI与请求目标相同。否则，有效请求URI的构造如下所示：
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".
如果服务器的配置（或出站网关）提供固定的URI方案，则该方案将用于有效的请求URI。否则，如果通过TLS安全TCP连接接收请求，则有效请求URI的方案为“https”；如果不是，则方案为“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.
如果服务器的配置（或出站网关）提供了固定的URI授权组件，则该授权将用于有效的请求URI。如果不是，那么如果请求目标是授权形式，则有效请求URI的授权组件与请求目标相同。如果不是，则如果主机标题字段提供了非空字段值，则权限组件与主机字段值相同。否则，将为授权组件分配为服务器配置的默认名称，如果连接的传入TCP端口号与有效请求URI方案的默认端口号不同，则将冒号（“：”）和传入端口号（十进制形式）附加到授权组件。
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.
如果请求目标是权威形式或星号形式，则有效请求URI的组合路径和查询组件为空。否则，组合的路径和查询组件与请求目标相同。
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.
有效请求URI的组件，一旦如上所述确定，就可以通过连接scheme“：/”、authority以及组合路径和查询组件组合成绝对URI形式。
Example 1: the following message received over an insecure TCP connection
示例1：通过不安全的TCP连接接收以下消息
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
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
http://www.example.org:8080/pub/WWW/TheProject.html
Example 2: the following message received over a TLS-secured TCP connection
示例2：通过TLS安全TCP连接接收以下消息
OPTIONS * HTTP/1.1 Host: www.example.org
选项*HTTP/1.1主机：www.example.org
has an effective request URI of
具有的有效请求URI为
https://www.example.org
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请求的收件人可能需要使用试探法（例如，检查URI路径以查找特定主机特有的内容），以便猜测有效请求URI的权限组件。
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提供服务。例如，请求可能有意或无意地被错误定向，使得接收到的请求目标或主机头字段中的信息与已建立连接的主机或端口不同。如果连接来自可信网关，则可能会出现不一致；否则，它可能表示有人试图绕过安全过滤器，欺骗服务器交付非公共内容，或毒害缓存。有关消息路由的安全注意事项，请参见第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不包括用于将给定请求消息与其对应的一个或多个响应消息关联的请求标识符。因此，它依赖于响应到达的顺序来精确地对应于在同一连接上发出请求的顺序。只有当一个或多个信息性响应（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.
一个连接上有多个未完成请求的客户端必须按照发送顺序维护一个未完成请求列表，并且必须将该连接上收到的每个响应消息与尚未收到最终（非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请求和响应的处理中扮演各种角色。一些中介用于提高性能或可用性。其他用于访问控制或过滤内容。由于HTTP流具有类似于管道和过滤器体系结构的特性，因此在中介可以增强（或干扰）流的任一方向的程度上没有固有的限制。
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.
不充当隧道的中介必须实现第6.1节中规定的连接头字段，并排除仅用于传入连接的字段。
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 "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email (Section 3.6.7 of [RFC5322]). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.
“Via”标题字段表示用户代理和服务器之间（根据请求）或源服务器和客户端之间（根据响应）存在中间协议和收件人，类似于电子邮件中的“Received”标题字段（RFC5322的第3.6.7节）。Via可用于跟踪消息转发，避免请求循环，以及识别请求/响应链中发送方的协议功能。
Via = 1#( received-protocol RWS received-by [ RWS comment ] )
Via=1#（由[RWS comment]接收的协议RWS接收）
received-protocol = [ protocol-name "/" ] protocol-version
; see Section 6.7
received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token
received-protocol = [ protocol-name "/" ] protocol-version
; see Section 6.7
received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token
Multiple Via field values represent each proxy or gateway that has forwarded the message. Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients.
多个Via字段值表示已转发消息的每个代理或网关。每个中介体都会附加自己关于消息接收方式的信息，以便根据转发收件人的顺序对最终结果进行排序。
A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards. An HTTP-to-HTTP gateway MUST send an appropriate Via header field in each inbound request message and MAY send a Via header field in forwarded response messages.
代理必须在其转发的每条消息中发送一个适当的Via标头字段，如下所述。HTTP-to-HTTP网关必须在每个入站请求消息中发送适当的Via标头字段，并且可以在转发的响应消息中发送Via标头字段。
For each intermediary, the received-protocol indicates the protocol and protocol version used by the upstream sender of the message. Hence, the Via field value records the advertised protocol capabilities of the request/response chain such that they remain visible to downstream recipients; this can be useful for determining what backwards-incompatible features might be safe to use in response, or within a later request, as described in Section 2.6. For brevity, the protocol-name is omitted when the received protocol is HTTP.
对于每个中介，接收到的协议指示消息的上游发送方使用的协议和协议版本。因此，Via字段值记录请求/响应链的通告协议能力，使得它们对下游接收者保持可见；如第2.6节所述，这有助于确定在响应中或在以后的请求中安全使用哪些向后不兼容的功能。为简洁起见，当接收的协议为HTTP时，将省略协议名称。
The received-by portion of the field value is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym. If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol.
字段值的received by部分通常是随后转发消息的收件人服务器或客户端的主机和可选端口号。但是，如果真实主机被认为是敏感信息，发送方可以用假名替换它。如果未提供端口，则接收方可能会将其解释为在所接收协议的默认TCP端口（如果有）上接收。
A sender MAY generate comments in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional, and a recipient MAY remove them prior to forwarding the message.
发送者可以在Via头字段中生成注释，以识别每个接收者的软件，类似于用户代理和服务器头字段。但是，Via字段中的所有注释都是可选的，收件人可以在转发邮件之前删除这些注释。
For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin server at www.example.com. The request received by www.example.com would then have the following Via header field:
例如，可以从HTTP/1.0用户代理向名为“fred”的内部代理发送请求消息，该代理使用HTTP/1.1将请求转发到p.example.net上的公共代理，该代理通过将请求转发到www.example.com上的源服务器来完成请求。然后，www.example.com接收到的请求将具有以下Via头字段：
Via: 1.0 fred, 1.1 p.example.net
Via:1.0 fred，1.1 p.example.net
An intermediary used as a portal through a network firewall SHOULD NOT forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, such an intermediary SHOULD replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.
作为通过网络防火墙的入口使用的中介不应转发防火墙区域内主机的名称和端口，除非已明确启用此功能。如果未启用，则此类中介应将防火墙后任何主机的主机接收到的每个主机替换为该主机的适当笔名。
An intermediary MAY combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol values. For example,
如果条目具有相同的接收协议值，则中介可以将Via报头字段条目的有序子序列组合成单个这样的条目。例如
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
Via:1.0瑞奇，1.1埃塞尔，1.1弗雷德，1.0露西
could be collapsed to
可能会倒塌到
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Via:1.0瑞奇，1.1默兹，1.0露西
A sender SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. A sender MUST NOT combine entries that have different received-protocol values.
发送方不应合并多个条目，除非它们都在同一组织控制下，并且主机已被假名替换。发送方不得组合具有不同接收协议值的条目。
Some intermediaries include features for transforming messages and their payloads. A proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems might occur when these transformations are applied to payloads intended for critical applications, such as medical imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the payload received is identical to the original.
一些中介体包括用于转换消息及其有效负载的功能。例如，代理可以在图像格式之间转换，以节省缓存空间或减少慢速链接上的通信量。然而，当这些转换应用于用于关键应用（如医疗成像或科学数据分析）的有效载荷时，可能会出现操作问题，特别是当使用完整性检查或数字签名来确保接收的有效载荷与原始载荷相同时。
An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify messages in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, or a privacy filter. Such transformations are presumed to be desired by whichever client (or client organization) selected the proxy.
如果HTTP-to-HTTP代理被设计或配置为以语义上有意义的方式修改消息（即，超出正常HTTP处理所需的修改，以对原始发送方或下游接收方有意义的方式更改消息），则称其为“转换代理”。例如，转换代理可能充当共享注释服务器（修改响应以包括对本地注释数据库的引用）、恶意软件过滤器、格式转码器或隐私过滤器。无论哪个客户（或客户组织）选择了代理，都假定希望进行这种转换。
If a proxy receives a request-target with a host name that is not a fully qualified domain name, it MAY add its own domain to the host name it received when forwarding the request. A proxy MUST NOT change the host name if the request-target contains a fully qualified domain name.
如果代理收到的请求目标的主机名不是完全限定的域名，它可以在转发请求时将自己的域添加到收到的主机名中。如果请求目标包含完全限定的域名，则代理不得更改主机名。
A proxy MUST NOT modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*".
代理在将接收到的请求目标转发到下一个入站服务器时，不得修改其“绝对路径”和“查询”部分，除非如上所述将空路径替换为“/”或“*”。
A proxy MAY modify the message body through application or removal of a transfer coding (Section 4).
代理可以通过应用或删除传输编码来修改消息体（第4节）。
A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of a message that contains a no-transform cache-control directive (Section 5.2 of [RFC7234]).
代理不得转换包含无转换缓存控制指令（RFC7234第5.2节）的消息的有效负载（RFC7231第3.3节）。
A proxy MAY transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a payload MUST add a Warning header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see Section 5.5 of [RFC7234]). A proxy that transforms the payload of a 200 (OK) response can further inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
代理可以转换不包含no transform cache control指令的消息的有效负载。转换有效负载的代理必须添加警告代码为214的警告头字段（“已应用转换”），如果消息中还没有警告头字段（请参见[RFC7234]第5.5节）。转换200（OK）响应的有效负载的代理可以通过将响应状态代码更改为203（非权威信息）（RFC7231的第6.3.4节）进一步通知下游接收方已应用转换。
A proxy SHOULD NOT modify header fields that provide information about the endpoints of the communication chain, the resource state, or the selected representation (other than the payload) unless the field's definition specifically allows such modification or the modification is deemed necessary for privacy or security.
代理不应修改提供有关通信链端点、资源状态或所选表示（有效负载除外）信息的头字段，除非该字段的定义明确允许此类修改，或者认为修改是隐私或安全所必需的。
HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s). HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request and response structures onto the data units of an underlying transport protocol is outside the scope of this specification.
HTTP消息传递独立于底层传输层或会话层连接协议。HTTP仅假定一种可靠的传输，请求按顺序传递，响应按顺序传递。HTTP请求和响应结构到底层传输协议的数据单元的映射不在本规范的范围内。
As described in Section 5.2, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the target URI. For example, the "http" URI scheme (Section 2.7.1) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use a proxy via some other connection, port, or protocol.
如第5.2节所述，用于HTTP交互的特定连接协议由客户端配置和目标URI确定。例如，“http”URI方案（第2.7.1节）表示TCP over IP的默认连接，默认TCP端口为80，但客户端可能被配置为通过其他连接、端口或协议使用代理。
HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request queues to enable fair use and detect denial-of-service attacks.
HTTP实现需要进行连接管理，包括维护当前连接的状态、建立新连接或重用现有连接、处理连接上接收的消息、检测连接故障以及关闭每个连接。大多数客户端并行维护多个连接，包括每个服务器端点有多个连接。大多数服务器设计用于维护数千个并发连接，同时控制请求队列以实现公平使用和检测拒绝服务攻击。
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.
“连接”标题字段允许发送方为当前连接指示所需的控制选项。为了避免混淆下游收件人，在转发邮件之前，代理或网关必须删除或替换任何接收到的连接选项。
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).
当连接之外的标题字段用于提供当前连接的控制信息时，发送方必须在连接标题字段中列出相应的字段名。在转发消息之前，代理或网关必须解析接收到的连接头字段，对于此字段中的每个连接选项，从消息中删除与连接选项同名的任何头字段，然后删除连接头字段本身（或将其替换为转发消息的中间层自己的连接选项）。
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 header（连接头）字段提供了一种声明性方式，用于区分仅针对直接收件人（“逐跳”）的头字段与针对链上所有收件人（“端到端”）的头字段，使消息能够自我描述，并允许部署未来特定于连接的扩展，而不用担心它们会被旧的中介盲目转发。
The Connection header field's value has the following grammar:
连接头字段的值具有以下语法：
Connection = 1#connection-option connection-option = token
连接=1#连接选项连接选项=令牌
Connection options are case-insensitive.
连接选项不区分大小写。
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]).
发送方不得发送与用于有效负载的所有接收方的标题字段对应的连接选项。例如，缓存控制永远不适合作为连接选项（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.
连接选项并不总是与消息中的头字段相对应，因为如果没有与连接选项相关联的参数，则可能不需要特定于连接的头字段。相反，在没有相应连接选项的情况下接收的特定于连接的报头字段通常表示该字段已被中介不正确地转发，收件人应忽略该字段。
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,
“关闭”连接选项是为发送方定义的，用于发出信号，表明此连接将在响应完成后关闭。例如
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).
在请求或响应头字段中，表示发送方将在当前请求/响应完成后关闭连接（第6.6节）。
A client that does not support persistent connections MUST send the "close" connection option in every request message.
不支持持久连接的客户端必须在每个请求消息中发送“关闭”连接选项。
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（信息性）状态代码的响应消息中发送“关闭”连接选项。
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默认使用“持久连接”，允许通过单个连接承载多个请求和响应。“关闭”连接选项用于表示在当前请求/响应之后连接将不会保持。HTTP实现应该支持持久连接。
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):
收件人根据最近收到的邮件的协议版本和连接头字段（如果有）确定连接是否持久：
o If the "close" connection option is present, the connection will not persist after the current response; else,
o 如果存在“关闭”连接选项，则在当前响应之后连接将不会持续；其他的
o If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,
o 如果收到的协议是HTTP/1.1（或更高版本），则连接将在当前响应之后保持；其他的
o 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,
o 如果收到的协议是HTTP/1.0，存在“保持活动”连接选项，收件人不是代理，并且收件人希望遵守HTTP/1.0“保持活动”机制，则连接将在当前响应后保持；否则
o The connection will close after the current response.
o 连接将在当前响应后关闭。
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.
客户端可能会在持久连接上发送额外的请求，直到它发送或接收到“关闭”连接选项，或者接收到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.
如第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客户端保持持久连接（有关许多HTTP/1.0客户端实现的Keep-Alive header字段问题的信息和讨论，请参阅[RFC2068]第19.7.1节）。
See Appendix A.1.2 for more information on backwards compatibility with HTTP/1.0 clients.
有关与HTTP/1.0客户端向后兼容的更多信息，请参见附录A.1.2。
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from asynchronous close events.
可以随时关闭连接，无论是否有意。实现应该预见到从异步关闭事件中恢复的需要。
When an inbound connection is closed prematurely, a client MAY open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent methods (Section 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry non-idempotent requests.
当入站连接过早关闭时，如果所有请求都具有幂等方法，客户端可能会打开新连接并自动重新传输中止的请求序列（RFC7231第4.2.2节）。代理不能自动重试非幂等请求。
A user agent MUST NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied. For example, a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that request automatically. Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed.
用户代理不能使用非幂等方法自动重试请求，除非它有某种方法可以知道请求语义实际上是幂等的，而不考虑方法，或者有某种方法可以检测到原始请求从未应用过。例如，知道（通过设计或配置）对给定资源的POST请求是安全的用户代理可以自动重复该请求。同样，专为在版本控制存储库上运行而设计的用户代理可能能够通过在连接失败后检查目标资源版本，恢复或修复部分应用的任何更改，然后自动重试失败的请求，从部分故障条件中恢复。
A client SHOULD NOT automatically retry a failed automatic retry.
客户端不应自动重试失败的自动重试。
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MAY process a sequence of pipelined requests in parallel if they all have safe methods (Section 4.2.1 of [RFC7231]), but it MUST send the corresponding responses in the same order that the requests were received.
支持持久连接的客户机可以“管道化”其请求（即，在不等待每个响应的情况下发送多个请求）。如果一系列流水线请求都有安全方法（RFC7231第4.2.1节），则服务器可以并行处理这些请求，但必须按照接收请求的相同顺序发送相应的响应。
A client that pipelines requests SHOULD retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client MUST NOT pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset problem described in Section 6.6).
如果连接在接收到所有相应响应之前关闭，则对请求进行管道化处理的客户端应重试未响应的请求。在连接失败（服务器在其最后一次完整响应中未显式关闭连接）后重试流水线请求时，客户端不得在连接建立后立即进行流水线处理，因为先前管道中的第一个剩余请求可能会导致错误响应，如果在过早关闭的连接上发送多个请求，则可能会再次丢失错误响应（请参阅第6.6节中描述的TCP重置问题）。
Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to pipelining because they can be automatically retried after a connection failure. A user agent SHOULD NOT pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
幂等方法（RFC7231的第4.2.2节）对于流水线非常重要，因为它们可以在连接失败后自动重试。用户代理不应在非幂等方法之后对请求进行管道化处理，直到收到该方法的最终响应状态代码，除非用户代理具有检测和从涉及管道化序列的部分故障条件中恢复的方法。
An intermediary that receives pipelined requests MAY pipeline those requests when forwarding them inbound, since it can rely on the outbound user agent(s) to determine what requests can be safely pipelined. If the inbound connection fails before receiving a response, the pipelining intermediary MAY attempt to retry a sequence of requests that have yet to receive a response if the requests all have idempotent methods; otherwise, the pipelining intermediary SHOULD forward any received responses and then close the corresponding outbound connection(s) so that the outbound user agent(s) can recover accordingly.
接收管道化请求的中介可以在将这些请求转发到入站时管道化这些请求，因为它可以依赖出站用户代理来确定哪些请求可以安全管道化。如果入站连接在接收响应之前失败，则管道中介可以尝试重试尚未接收响应的一系列请求（如果这些请求都具有幂等方法）；否则，管道中介应该转发任何接收到的响应，然后关闭相应的出站连接，以便出站用户代理可以相应地恢复。
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.
多个连接通常用于避免“线路头阻塞”问题，其中需要大量服务器端处理和/或具有较大负载的请求会阻塞同一连接上的后续请求。但是，每个连接都会消耗服务器资源。此外，在拥挤的网络中，使用多个连接可能会导致不良的副作用。
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.
请注意，服务器可能会拒绝其认为具有滥用性或拒绝服务攻击特征的流量，例如来自单个客户端的大量打开连接。
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.
希望超时的客户端或服务器应在连接上发出优美的关闭。实现应该持续监视打开的连接，以获取接收到的关闭信号，并根据需要对其做出响应，因为连接两侧的快速关闭可以回收分配的系统资源。
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.
发送消息体的客户端应在传输请求时监视网络连接是否有错误响应。如果客户端看到一个响应，表明服务器不希望接收消息正文并正在关闭连接，则客户端应立即停止传输正文并关闭其连接端。
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.
连接头字段（第6.1节）提供了一个“关闭”连接选项，当发送方希望在当前请求/响应对之后关闭连接时，应发送该选项。
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.
发送“关闭”连接选项的客户端不得在该连接上发送进一步的请求（在包含“关闭”的连接之后），并且必须在读取与该请求对应的最终响应消息后关闭连接。
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.
发送“关闭”连接选项的服务器必须在发送包含“关闭”的响应后启动连接关闭（见下文）。服务器不得处理在该连接上收到的任何其他请求。
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.
接收到“关闭”连接选项的客户端必须停止在该连接上发送请求，并在读取包含“关闭”选项的响应消息后关闭连接；如果在连接上发送了其他流水线请求，则客户端不应假定这些请求将由服务器处理。
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堆栈将向客户端发送重置数据包；不幸的是，在客户端的HTTP解析器读取和解释未确认的输入缓冲区之前，重置数据包可能会擦除客户端的输入缓冲区。
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重置问题，服务器通常分阶段关闭连接。首先，服务器通过只关闭读/写连接的写端来执行半关闭。然后，服务器继续从连接读取数据，直到它接收到客户端的相应关闭，或者直到服务器合理地确定其自己的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 = 1#protocol
升级=1#协议
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
发送101（交换协议）响应的服务器必须发送一个Upgrade header字段，以指示要将连接切换到的新协议；如果切换多个协议层，发送方必须按层升序列出协议。服务器不得切换到客户端未在相应请求的升级标头字段中指示的协议。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.
服务器可以选择忽略客户端指示的优先顺序，并基于其他因素（如请求的性质或服务器上的当前负载）选择新协议。
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（需要升级）响应的服务器必须发送一个升级头字段，以指示可接受的协议，按首选项降序排列。
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.
服务器可以在任何其他响应中发送一个升级头字段，以便在适合未来请求时，按照优先级降序公布它实现了对升级到所列协议的支持。
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
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（交换协议）响应后，服务器将立即继续响应原始请求，就像它在新协议中收到了等效请求一样（即，在协议更改后，服务器仍有一个未完成的请求需要满足，并且希望这样做而不需要重复该请求）。
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 header字段，并且服务器决定切换协议，则它首先在HTTP/1.1中使用101（切换协议）消息进行响应，然后立即使用新协议的等效响应对目标资源上的GET进行响应。这允许将连接升级到与HTTP具有相同语义的协议，而无需额外往返的延迟成本。服务器不得切换协议，除非新协议能够遵守接收到的消息语义；任何协议都可以满足选项请求。
The following is an example response to the above hypothetical request:
以下是对上述假设请求的示例响应：
HTTP/1.1 101 Switching Protocols Connection: upgrade Upgrade: HTTP/2.0
HTTP/1.1 101交换协议连接：升级：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 ...]
[…数据流切换到HTTP/2.0，并对“GET/hello.txt”请求做出适当的响应（由新协议定义）…]
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.
发送升级时，发送方还必须发送包含“升级”连接选项的连接头字段（第6.1节），以防止可能未实现所列协议的中介机构意外转发升级。服务器必须忽略HTTP/1.0请求中接收的升级标头字段。
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.
客户端不能在连接上开始使用升级的协议，直到它完全发送请求消息（即，客户端不能改变它在消息的中间发送的协议）。如果服务器接收到升级和带有“100 continue”（100 continue）预期的Expect标头字段（RFC7231）第5.1.1节），则服务器必须在发送101（交换协议）响应之前发送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 header字段仅适用于现有连接之上的交换协议；它不能用于切换基础连接（传输）协议，也不能将现有通信切换到其他连接。出于这些目的，更适合使用3xx（重定向）响应（RFC7231第6.4节）。
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.
本规范仅定义供超文本传输协议系列使用的协议名称“HTTP”，如第2.6节的HTTP版本规则和本规范的未来更新所定义。应使用第8.6节规定的注册程序向IANA注册其他代币。
A #rule extension to the ABNF rules of [RFC5234] is used to improve readability in the definitions of some header field values.
[RFC5234]的ABNF规则的#规则扩展用于提高某些标题字段值定义的可读性。
A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS).
定义了一个构造“#”，类似于“*”，用于定义以逗号分隔的元素列表。完整形式为“<n>#<m>元素”，表示至少<n>和最多<m>元素，每个元素之间用一个逗号（“，”）和可选空格（OWS）分隔。
In any production that uses the list construct, a sender MUST NOT generate empty list elements. In other words, a sender MUST generate lists that satisfy the following syntax:
在任何使用列表构造的产品中，发送方不得生成空的列表元素。换句话说，发送方必须生成满足以下语法的列表：
1#element => element *( OWS "," OWS element )
1#element => element *( OWS "," OWS element )
and:
以及：
#element => [ 1#element ]
#element => [ 1#element ]
and for n >= 1 and m > 1:
对于n>=1和m>1：
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax:
为了与旧式列表规则兼容，收件人必须解析并忽略合理数量的空列表元素：足以处理合并值的发件人的常见错误，但不能太多，以至于可以将其用作拒绝服务机制。换句话说，收件人必须接受满足以下语法的列表：
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Empty elements do not contribute to the count of elements present. For example, given these ABNF productions:
空元素不影响当前元素的计数。例如，考虑到这些ABNF产品：
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.6
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 3.2.6
Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only):
下面是示例列表的有效值（不包括双引号，双引号仅用于定界）：
"foo,bar" "foo ,bar," "foo , ,bar,charlie "
“foo，bar”“foo，bar”“foo，bar，charlie”
In contrast, the following values would be invalid, since at least one non-empty element is required by the example-list production:
相反，以下值将无效，因为示例列表生产至少需要一个非空元素：
"" "," ", ,"
"" "," ","
Appendix B shows the collected ABNF for recipients after the list constructs have been expanded.
附录B显示了列表结构展开后为收件人收集的ABNF。
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<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]).
本文档定义了以下HTTP头字段，因此“永久消息头字段名称”注册表已相应更新（请参见[BCP90]）。
+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+
+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+
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).
此外，报头字段名“Close”已注册为“reserved”，因为将该名称用作HTTP报头字段可能与连接报头字段的“Close”连接选项冲突（第6.1节）。
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
IANA maintains the registry of URI Schemes [BCP115] at <http://www.iana.org/assignments/uri-schemes/>.
IANA在以下位置维护URI方案注册表[BCP115]<http://www.iana.org/assignments/uri-schemes/>.
This document defines the following URI schemes, so the "Permanent URI Schemes" registry has been updated accordingly.
本文档定义了以下URI方案，因此“永久URI方案”注册表已相应更新。
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
IANA maintains the registry of Internet media types [BCP13] at <http://www.iana.org/assignments/media-types>.
IANA在以下位置维护互联网媒体类型注册表[BCP13]<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.
本文档作为Internet媒体类型“消息/http”和“应用程序/http”的规范。以下内容已在IANA注册。
The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.
message/http类型可用于封装单个http请求或响应消息，前提是它遵守有关行长度和编码的所有“消息”类型的MIME限制。
Type name: message
类型名称：消息
Subtype name: http
子类型名称：http
Required parameters: N/A
所需参数：不适用
Optional parameters: version, msgtype
可选参数：版本、msgtype
version: The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
版本：随附消息的HTTP版本号（例如，“1.1”）。如果不存在，则可从正文的第一行确定版本。
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
msgtype：消息类型--“请求”或“响应”。如果不存在，则可从主体的第一行确定类型。
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
编码注意事项：只允许使用“7位”、“8位”或“二进制”
Security considerations: see Section 9
安全注意事项：见第9节
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: This specification (see Section 8.3.1).
出版规范：本规范（见第8.3.1节）。
Applications that use this media type: N/A
使用此媒体类型的应用程序：不适用
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
Magic number(s): N/A
Magic number(s): N/A
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: See Authors' Addresses section.
作者：参见作者地址部分。
Change controller: IESG
更改控制器：IESG
The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).
application/http类型可用于封装一个或多个http请求或响应消息（不混合）的管道。
Type name: application
类型名称：应用程序
Subtype name: http
子类型名称：http
Required parameters: N/A
所需参数：不适用
Optional parameters: version, msgtype
可选参数：版本、msgtype
version: The HTTP-version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
版本：所附消息的HTTP版本号（例如，“1.1”）。如果不存在，则可从正文的第一行确定版本。
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
msgtype：消息类型--“请求”或“响应”。如果不存在，则可从主体的第一行确定类型。
Encoding considerations: HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via email.
编码注意事项：此类型包含的HTTP消息采用“二进制”格式；通过电子邮件传输时，需要使用适当的内容传输编码。
Security considerations: see Section 9
安全注意事项：见第9节
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: This specification (see Section 8.3.2).
出版规范：本规范（见第8.3.2节）。
Applications that use this media type: N/A
使用此媒体类型的应用程序：不适用
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: See Authors' Addresses section.
作者：参见作者地址部分。
Change controller: IESG
更改控制器：IESG
The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at <http://www.iana.org/assignments/http-parameters>.
“HTTP传输编码注册表”定义传输编码名称的命名空间。维持在<http://www.iana.org/assignments/http-parameters>.
Registrations MUST include the following fields:
注册必须包括以下字段：
o Name
o 名称
o Description
o 描述
o Pointer to specification text
o 指向规范文本的指针
Names of transfer codings MUST NOT overlap with names of content codings (Section 3.1.2.1 of [RFC7231]) unless the encoding transformation is identical, as is the case for the compression codings defined in Section 4.2.
传输编码的名称不得与内容编码的名称重叠（RFC7231第3.1.2.1节），除非编码转换相同，如第4.2节中定义的压缩编码。
Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding defined in this specification.
添加到此名称空间的值需要IETF审查（见[RFC5226]第4.1节），并且必须符合本规范中定义的传输编码目的。
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
使用程序名来识别编码格式是不可取的，不鼓励在将来进行编码。
The "HTTP Transfer Coding Registry" has been updated with the registrations below:
“HTTP传输编码注册表”已更新为以下注册：
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
IANA maintains the "HTTP Content Coding Registry" at <http://www.iana.org/assignments/http-parameters>.
IANA在以下位置维护“HTTP内容编码注册表”<http://www.iana.org/assignments/http-parameters>.
The "HTTP Content Coding Registry" has been updated with the registrations below:
“HTTP内容编码注册表”已更新为以下注册：
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
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）升级令牌注册表”定义协议名称令牌的命名空间，用于在升级头字段中标识协议。登记处设在<http://www.iana.org/assignments/http-upgrade-tokens>.
Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded.
每个注册的协议名称都与联系人信息和一组可选规范相关联，这些规范详细说明了升级后如何处理连接。
Registrations happen on a "First Come First Served" basis (see Section 4.1 of [RFC5226]) and are subject to the following rules:
注册以“先到先得”的方式进行（见[RFC5226]第4.1节），并遵守以下规则：
1. A protocol-name token, once registered, stays registered forever.
1. 协议名称令牌一旦注册，将永远保持注册状态。
2. The registration MUST name a responsible party for the registration.
2. 注册必须指定负责注册的一方。
3. The registration MUST name a point of contact.
3. 注册必须指定一个联系人。
4. The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available.
4. 注册可以命名与该令牌相关联的一组规范。此类规范无需公开。
5. The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
5. 注册时应命名一组与该令牌关联的预期“协议版本”令牌。
6. The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
6. 责任方可随时更改注册。IANA将保留所有此类变更的记录，并应要求提供这些变更。
7. The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted.
7. IESG可以重新分配协议令牌的责任。这通常仅在无法联系到责任方的情况下使用。
This registration procedure for HTTP Upgrade Tokens replaces that previously defined in Section 7.2 of [RFC2817].
HTTP升级令牌的注册过程取代了[RFC2817]第7.2节中先前定义的注册过程。
The "HTTP" entry in the upgrade token registry has been updated with the registration below:
升级令牌注册表中的“HTTP”项已更新，注册如下：
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
责任方为：“IETF(iesg@ietf.org)-互联网工程工作队”。
This section is meant to inform developers, information providers, and users of known security considerations relevant to HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in [RFC7231].
本节旨在告知开发人员、信息提供商和用户与HTTP消息语法、解析和路由相关的已知安全注意事项。[RFC7231]中介绍了有关HTTP语义和有效负载的安全注意事项。
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依赖于权威响应的概念：根据响应消息发起时目标资源的状态，由目标URI中标识的权威（或在其指示下）确定为该请求最合适的响应的响应。提供来自非权威源（如共享缓存）的响应通常有助于提高性能和可用性，但仅限于源可以被信任或不受信任的响应可以安全使用的范围。
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.
超文本，可能通过用户信息混淆权限组件来辅助（见第2.7.1节）。用户代理可以通过以下方式减少网络钓鱼攻击的影响：允许用户在执行操作之前轻松检查目标URI；在存在用户信息时显著区分（或拒绝）用户信息；当引用文档来自未知或不受信任的源时，不发送存储的凭据和cookie。
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.
当在授权组件中使用注册名称时，“http”URI方案（第2.7.1节）依赖于用户的本地名称解析服务来确定在何处可以找到授权响应。这意味着对用户的网络主机表、缓存名称或名称解析库的任何攻击都会成为攻击建立权限的途径。同样，用户为域名服务（DNS）选择服务器以及从中获得解析结果的服务器层次结构可能会影响地址映射的真实性；DNS安全扩展（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建立权限容易受到对Internet协议路由的攻击。
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的授权组件匹配（参见[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 that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 8 of [RFC7234].
如[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).
实现者需要考虑它们的设计和编码决策的隐私和安全含义，以及它们为操作员提供的配置选项（特别是默认配置）。
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主要使用文本、字符分隔的字段，解析器通常容易受到基于发送非常长（或非常慢）数据流的攻击，特别是在实现需要没有预定义长度的协议元素的情况下。
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节）的最小大小限制提出了具体建议。这些都是最低限度的建议，即使是资源有限的实施也可以支持这些建议；预计大多数实现将选择更高的限制。
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.
响应拆分（也称为CRLF注入）是一种常见的技术，用于对Web使用的各种攻击，它利用HTTP消息帧的基于行的特性以及请求与持久连接上响应的有序关联[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.
随后的响应已开始，响应已被拆分，第二个响应中的内容由攻击者控制。然后，攻击者可以在同一个持久连接上发出任何其他请求，并诱使收件人（包括中间人）相信拆分的后半部分是对第二个请求的权威回答。
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 header字段中回显。如果该参数由应用程序解码，并且在放入响应字段时未正确编码，则攻击者可以发送编码的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解码，而不是更模糊的数据转换，如字符集转码、XML实体转换、base64解码、sprintf重新格式化、，等。更有效的缓解措施是防止除服务器的核心协议库以外的任何东西在标头部分内发送CR或LF，这意味着将标头字段的输出限制为过滤坏八位字节的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.
请求走私（[Linhart]）是一种技术，它利用不同接收者之间协议解析的差异，在一个看似无害的请求中隐藏额外的请求（否则可能会被策略阻止或禁用）。与响应拆分一样，请求走私可能导致对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.
本规范引入了关于请求解析的新要求，特别是第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
HTTP没有定义确保消息完整性的特定机制，而是依赖于底层传输协议的错误检测能力以及使用长度或区块分隔的帧来检测完整性。附加的完整性机制，例如应用于内容的哈希函数或数字签名，可以通过可扩展的方法选择性地添加到消息中
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通信的非正式性质证明了缺乏单一完整性机制的合理性。然而，HTTP作为一种信息访问机制的流行已导致其在验证消息完整性至关重要的环境中的使用日益增加。
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被专门设计为独立于传输协议，因此它可以在许多不同形式的加密连接上使用，通过选择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日志信息本质上是保密的；其处理往往受到法律法规的限制。日志信息需要安全存储，并遵循适当的准则进行分析。在单个条目中匿名个人信息会有所帮助，但这通常不足以防止基于与其他访问特征的相关性重新识别真实日志跟踪。因此，即使密钥是假名，对特定客户端设置密钥的访问跟踪发布也不安全。
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.
为了最大限度地降低被盗或意外发布的风险，一旦日志信息不再需要支持安全、审计或欺诈控制的操作需求，就应该清除日志信息中的个人身份信息，包括用户标识符、IP地址和用户提供的查询参数。
This edition of HTTP/1.1 builds on the many contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including substantial contributions made by the previous authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, and Paul J. Leach. Mark Nottingham oversaw this effort as Working Group Chair.
这个版本的HTTP/1.1建立在RFC 1945、RFC 2068、RFC 2145和RFC 2616的许多贡献的基础上，包括以前的作者、编辑和工作组主席所做的大量贡献：Tim Berners Lee、Ari Luotnen、Roy T.Fielding、Henrik Frystyk Nielsen、Jim Gettys、Jeffrey C.Mogul、Larry Masinter、，保罗·J·利奇。马克·诺丁汉作为工作组主席监督这项工作。
Since 1999, the following contributors have helped improve the HTTP specification by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating open issues:
自1999年以来，以下贡献者通过报告错误、提出智能问题、起草或审查文本以及评估未决问题，帮助改进了HTTP规范：
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole, Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens, Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
亚当·巴特、亚当·罗奇、艾迪生·菲利普斯、阿德里安·查德、阿德里安·科尔、阿德里安·德克罗伊、艾伦·福特、艾伦·拉滕伯格、阿尔伯特·隆德、阿莱克·斯托姆、亚历克斯·罗斯科夫、亚历山大·莫高、亚历克斯·梅尔尼科夫、艾莉莎·史密斯、阿米卡·罗斯曼、阿米特·克莱因、阿莫斯·杰弗里斯、安德烈亚斯·梅尔、安德烈亚斯·彼得森、安德烈·波波波夫、阿尼尔·夏玛、安妮·范·凯斯特伦、安东尼·布莱恩、，阿斯比约恩·阿尔斯伯格、阿肖克·库马尔、巴拉昌德·克里希纳穆尔西、巴里·莱巴、本·劳里、本杰明·卡莱尔、本杰明·尼文·詹金斯、贝诺特·克莱斯、比尔·科里、比尔·伯克、比约恩·霍尔曼、鲍勃·谢弗勒、鲍里斯·兹巴斯基、布雷特·斯莱特金、布赖恩·凯尔、布赖恩·麦克巴伦、布赖恩·潘恩、布赖恩·雷莫尔、布赖恩·史密斯、布鲁斯·佩伦斯、布莱斯·内斯比特、卡梅隆·哈文·琼斯、，卡尔·库格勒、卡斯滕·鲍曼、查尔斯·弗莱、克里斯·伯德斯、克里斯·纽曼、克里斯蒂安·惠特玛、塞勒斯·达布、戴尔·罗伯特·安德森、丹·温、丹·温、丹·斯滕伯格、达雷尔·米勒、戴夫·克里德兰、戴夫·克罗克、戴夫·克里斯托、戴夫·泰勒、大卫·布斯、大卫·辛格、大卫·W·莫里斯、迪瓦卡尔·谢蒂、德米特里·库罗奇金、德蒙德·里德、杜安·韦塞尔、，爱德华·李、艾丹·阿德勒、艾略特·李尔、埃米尔·斯蒂芬、埃兰·哈默·拉哈夫、埃里克·D·威廉姆斯、埃里克·J·鲍曼、埃里克·劳伦斯、埃里克·雷斯科拉、埃里克·阿罗内斯蒂、翁君毅、埃文·普罗德罗莫、菲利克斯·盖森多费尔、弗洛里安·魏默、弗兰克·埃勒曼、弗雷德·阿卡林、弗雷德·博勒、弗雷德里克·凯泽、加博·莫尔纳、加布里埃尔·黑山、杰弗里·斯奈登、格瓦塞·马卡姆、，吉利·扎巴里、格雷厄姆·格里夫、格雷格·斯莱帕克、格雷格·威尔金斯、格泽戈兹·卡尔考斯基、哈拉尔德·特维特·阿尔韦斯特朗、哈利·哈尔平、赫尔格·赫斯、亨里克·诺德斯特罗姆、亨利·S·汤普森、亨利·斯托里、赫伯特·范·德·桑佩尔、赫尔夫·鲁兰、霍华德·梅尔曼、雨果·哈斯、伊恩·费特、伊恩·希克森、伊多·萨弗鲁蒂、伊拉里·柳斯瓦拉、伊利亚·格里戈里克、英戈·斯特克、J·罗斯·尼科尔、，詹姆斯·克鲁斯，詹姆斯·马格尔，詹姆斯·莱西，詹姆斯·M·斯内尔，杰米
Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault, Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge, Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska, Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence (who maintained the original issues list), Sean B. Palmer, Sean Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, and Zhong Yu.
Lokier、Jan Algermissen、Jari Arkko、Jeff Hodges（提出“有效请求URI”一词的人）、Jeff Pinner、Jeff Walden、Jim Luther、Jitu Padhye、Joe D.Williams、Joe Gregorio、Joe Orton、Joel Jaeggli、John C.Klensin、John C.Mallery、John Cowan、John Kemp、John Panzer、John Schneider、John Stracke、John Sullivan、Jonas Sicking、，乔纳森·里斯、乔纳森·比林顿、乔纳森·摩尔、乔纳森·西尔维拉、乔迪·罗斯、乔里斯·多贝尔斯汀、乔什·科恩、朱利安·皮埃尔、申荣志、贾斯汀·查普韦斯克、贾斯汀·查普韦斯克、贾斯汀·伦克兰茨、贾斯汀·詹姆斯、卡尔文德·辛格、卡尔·杜伯斯特、凯瑟琳·莫里亚蒂、基思·霍夫曼、基思·摩尔、肯·默奇森、科恩·霍特曼、康斯坦丁·沃龙科夫、克里斯·齐普、莱夫·赫斯特罗姆、，莱昂内尔·莫兰德、丽莎·杜肖奥、马基·斯塔乔亚克、马努·斯波尼、马克·施耐德、马克·斯莱姆科、马克·贝克、马克·保利、马克·沃森、马库斯·伊索马基、马库斯·兰塔勒、马丁·杜尔斯、马丁·穆萨托夫、马丁·尼尔森、马丁·汤姆森、马特·林奇、马修·考克斯、马修·克温、马克斯·克拉克、梅纳赫姆·道奇、梅拉尔·谢拉齐普尔、迈克尔·布伦斯、，Michael Hausenblas，Michael Scharf，Michael Sweet，Michael Tuexen，Michael Welzl，Mike Amundsen，Mike Belshe，Mike Bishop，Mike Kelly，Mike Schinkel，Miles Sabin，Murray S.Kucherawy，Mykyta Yevstifeyev，Nathan Rixham，Nicholas Shanks，Nico Williams，Nicolas Alvarez，Nicolas Mailhot，Noah Slater，Osama S.Mazahir，Pablo Castro，Pat Hayes，帕特里克·R·麦克马纳斯、保罗·E·琼斯、保罗·霍夫曼、保罗·马奎斯、彼得·雷斯卡、彼得·奥西尔、彼得·圣安德烈、彼得·沃特金斯、菲尔·阿彻、菲尔·亨特、菲利普·莫金、菲利普·哈勒姆·贝克、彼得·多布罗戈斯特、波尔·海宁·坎普、普里西·纳塔拉扬、拉杰夫·贝克托、雷·波尔克、雷托·巴赫曼·格默尔、理查德·巴恩斯、理查德·西甘尼亚克、罗布·特雷斯、，罗比·辛普森、罗伯特·布鲁尔、罗伯特·柯林斯、罗伯特·马特森、罗伯特·奥卡拉汉、罗伯特·奥洛夫森、罗伯特·赛尔、罗伯特·西默、罗伯特·德王尔德、罗伯特·哈维尔·戈多伊、罗伯特·佩恩、罗兰·津克、罗尼·维贾亚、瑞安·汉密尔顿、S·迈克·迪尔肯、萨尔瓦托·洛雷托、萨姆·约翰斯顿、萨姆·普拉拉、萨姆·鲁比、索拉布·库尔卡尼、斯科特·劳伦斯（谁维护原始问题列表）肖恩·帕尔默、肖恩·特纳、塞巴斯蒂安·巴努德、谢恩·麦卡伦、大津重吉、西蒙·亚德、斯蒂芬·艾辛、斯蒂芬·蒂尔科夫、斯蒂芬·哈哈拉基斯、斯蒂芬·鲍茨迈耶、斯蒂芬·法雷尔、斯蒂芬·肯特、斯蒂芬·卢丁、斯图亚特·威廉姆斯、Subbu·阿拉马拉朱、Subramanian Moonesamy、苏珊·哈雷斯、西尔万·海勒戈尔奇、塔潘·迪维卡、塔苏希罗·津卡瓦、塔苏亚Hayashi、Ted Hardie、Ted Lemon、Thomas Broyer、Thomas Fossati、Thomas Maslen、Thomas Nadeau、Thomas Nordin、Thomas Roessler、Tim Bray、Tim Morgan、Tim Olsen、Tom Zhou、Travis Snoozy、Tyler Close、Vincent Murphy、Zhu Werner Baumann、Wilbur Streett、Wilfredo Sanchez Vega、William A.Rowe Jr、William Chan、Willy Tarreau、王晓树、YaronGoland、Yngve Nysaeter Pettersen、Yoav Nir、Yogesh Bang、Yuchong Cheng、Yutaka Oiwa、Yves Lafon（编辑团队长期成员）、Zed A.Shaw和钟宇。
See Section 16 of [RFC2616] for additional acknowledgements from prior revisions.
参见[RFC2616]第16节，了解先前版本的其他确认。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch，L.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[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.
[RFC1952]Deutsch，P.，Gailly，J-L.，Adler，M.，Deutsch，L.，和G.Randers Pehrson，“GZIP文件格式规范版本4.3”，RFC 1952，1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：条件请求”，RFC 7232，2014年6月。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，2014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，2014年6月。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，2014年6月。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[USASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[Welch] Welch, T., "A Technique for High-Performance Data Compression", IEEE Computer 17(6), June 1984.
[Welch]Welch，T.，“高性能数据压缩技术”，IEEE Computer 17（6），1984年6月。
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
[BCP115]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 115，RFC 4395，2006年2月。
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[BCP13]Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[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>.
[Georgiev]Georgiev，M.，Iyengar，S.，Jana，S.，Anubhai，R.，Boneh，D.，和V.Shmatikov，“世界上最危险的代码：在非浏览器软件中验证SSL证书”，2012年ACM计算机和通信安全会议记录（CCS'12），第38-49页，2012年10月<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.
[ISO-8859-1]国际标准化组织，“信息技术——8位单字节编码图形字符集——第1部分：拉丁字母表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>.
[Klein]Klein，A.，“分而治之-HTTP响应分裂、Web缓存中毒攻击和相关主题”，2004年3月<http://packetstormsecurity.com/ papers/general/whitepaper\u 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>.
[Kristol，D.，“HTTP Cookies：标准、隐私和政治”，ACM互联网技术交易1（2），2001年11月<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>.
[Linhart]Linhart，C.，Klein，A.，Heled，R.，和S.Orrin，“HTTP请求走私”，2005年6月<http://www.watchfire.com/news/whitepapers.aspx>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996.
[RFC1919]Chatel，M.，“经典与透明IP代理”，RFC19191996年3月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]菲尔丁，R.，盖蒂，J.，莫格尔，J.，尼尔森，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
[RFC2145]Mogul，J.，Fielding，R.，Gettys，J.，和H.Nielsen，“HTTP版本号的使用和解释”，RFC 2145，1997年5月。
[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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC3040]Cooper，I.，Melve，I.，和G.Tomlinson，“互联网Web复制和缓存分类法”，RFC 3040，2001年1月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006.
[RFC4559]Jaganathan，K.，Zhu，L.，和J.Brezak，“Microsoft Windows中基于SPNEGO的Kerberos和NTLM HTTP身份验证”，RFC 4559，2006年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，“互联网信息格式”，RFC5222008年10月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, April 2012.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC6585，2012年4月。
HTTP has been in use since 1990. The first version, later referred to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet, using only a single request method (GET) and no metadata. HTTP/1.0, as defined by [RFC1945], added a range of request methods and MIME-like messaging, allowing for metadata to be transferred and modifiers placed on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely implemented applications calling themselves "HTTP/1.0" further necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.
HTTP自1990年开始使用。第一个版本，后来被称为HTTP/0.9，是一个简单的跨Internet超文本数据传输协议，只使用一个请求方法（GET），不使用元数据。[RFC1945]定义的HTTP/1.0添加了一系列请求方法和类似MIME的消息传递，允许传输元数据并在请求/响应语义上放置修饰符。但是，HTTP/1.0没有充分考虑分层代理、缓存、持久连接的需要或基于名称的虚拟主机的影响。称自己为“HTTP/1.0”的未完全实现的应用程序的激增进一步要求更改协议版本，以便两个通信应用程序确定彼此的真实功能。
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding only those features that can either be safely ignored by an HTTP/1.0 recipient or only be sent when communicating with a party advertising conformance with HTTP/1.1.
HTTP/1.1仍然与HTTP/1.0兼容，它包括了更严格的要求，支持可靠的实现，只添加了那些可以被HTTP/1.0接收者安全忽略的功能，或者只有在与一方通信时才能发送这些功能，以宣传与HTTP/1.1的一致性。
HTTP/1.1 has been designed to make supporting previous versions easy. A general-purpose HTTP/1.1 server ought to be able to understand any valid request in the format of HTTP/1.0, responding appropriately with an HTTP/1.1 message that only uses features understood (or safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client can be expected to understand any valid HTTP/1.0 response.
HTTP/1.1旨在使支持以前的版本变得容易。通用HTTP/1.1服务器应该能够理解HTTP/1.0格式的任何有效请求，并使用HTTP/1.1消息进行适当响应，该消息只使用HTTP/1.0客户端理解（或安全忽略）的功能。同样，HTTP/1.1客户端可以理解任何有效的HTTP/1.0响应。
Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests caused by a client failing to properly encode the request-target.
由于HTTP/0.9不支持请求中的头字段，因此它没有支持基于名称的虚拟主机的机制（通过检查主机头字段来选择资源）。任何实现基于名称的虚拟主机的服务器都应该禁用对HTTP/0.9的支持。事实上，大多数看起来是HTTP/0.9的请求都是由客户端未能正确编码请求目标而导致的构造不良的HTTP/1.x请求。
This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.
本节总结了HTTP/1.0和HTTP/1.1版本之间的主要差异。
The requirements that clients and servers support the Host header field (Section 5.4), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among the most important changes defined by HTTP/1.1.
HTTP/1.1定义的最重要更改包括：客户端和服务器支持主机头字段（第5.4节）、在HTTP/1.1请求中丢失错误时报告错误以及接受绝对URI（第5.3节）。
Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism for distinguishing the intended server of a request than the IP address to which that request was directed. The Host header field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers, additional requirements were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing, most HTTP-based services are dependent upon the Host header field for targeting requests.
较旧的HTTP/1.0客户端假定IP地址和服务器之间存在一对一的关系；除了请求所指向的IP地址之外，没有其他已建立的机制来区分请求的预期服务器。Host header字段是在HTTP/1.1的开发过程中引入的，尽管大多数HTTP/1.0浏览器都很快实现了它，但为了确保完全采用，对所有HTTP/1.1请求都提出了额外的要求。在撰写本文时，大多数基于HTTP的服务都依赖于主机头字段来定位请求。
In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections described in Section 19.7.1 of [RFC2068].
在HTTP/1.0中，每个连接在请求之前由客户端建立，在发送响应之后由服务器关闭。但是，一些实现实现了[RFC2068]第19.7.1节中描述的显式协商（“保持活动”）版本的持久连接。
Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0 persistent connections are faulty; for example, if an HTTP/1.0 proxy server doesn't understand Connection, it will erroneously forward that header field to the next inbound server, which would result in a hung connection.
一些客户机和服务器可能希望通过使用“Connection:keep-alive”请求头字段为它们显式协商，与以前的持久连接方法兼容。然而，HTTP/1.0持久连接的一些实验实现是错误的；例如，如果HTTP/1.0代理服务器不理解连接，它将错误地将该头字段转发到下一个入站服务器，这将导致挂起连接。
One attempted solution was the introduction of a Proxy-Connection header field, targeted specifically at proxies. In practice, this was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed above.
一种尝试性的解决方案是引入代理连接头字段，专门针对代理。在实践中，这也是不可行的，因为代理通常部署在多个层中，从而导致上面讨论的相同问题。
As a result, clients are encouraged not to send the Proxy-Connection header field in any requests.
因此，建议客户机在任何请求中都不要发送代理连接头字段。
Clients are also encouraged to consider the use of Connection: keep-alive in requests carefully; while they can enable persistent connections with HTTP/1.0 servers, clients using them will need to monitor the connection for "hung" requests (which indicate that the client ought stop sending the header field), and this mechanism ought not be used by clients at all when a proxy is being used.
客户也被鼓励考虑使用连接：仔细地在请求中保持活力；虽然它们可以启用与HTTP/1.0服务器的持久连接，但使用它们的客户端将需要监视“挂起”请求的连接（这表明客户端应该停止发送头字段），并且在使用代理时客户端根本不应该使用此机制。
HTTP/1.1 introduces the Transfer-Encoding header field (Section 3.3.1). Transfer codings need to be decoded prior to forwarding an HTTP message over a MIME-compliant protocol.
HTTP/1.1引入了传输编码头字段（第3.3.1节）。在通过MIME兼容协议转发HTTP消息之前，需要对传输编码进行解码。
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版本ABNF产品已明确区分大小写。此外，版本号被限制为单个数字，因为已知的实现不正确地处理多个数字的版本号。（第2.6节）
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中是不允许的，因为与它们在线路上的传输有关的安全问题。（第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节中完成。此外，它还意味着端到端的安全性。（第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消息可以（并且经常）由实现缓冲；尽管HTTP有时可以作为流使用，但它基本上是一种面向消息的协议。建议了各种协议元素的最小支持大小，以提高互操作性。（第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)
现在需要拒绝字段名周围的无效空格，因为接受它表示存在安全漏洞。ABNF productions定义的标题字段现在只列出字段值。（第3.2节）
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)
不推荐使用跨多行的标题字段（“行折叠”）。（第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八位组，并且已澄清了其中反斜杠转义的处理。引号对规则不再允许转义HTAB以外的控制字符。标题字段中的非美国ASCII内容和原因短语已被废弃并变得不透明（文本规则已删除）。（第3.2.6节）
Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2)
伪内容长度标题字段现在需要由收件人作为错误处理。（第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)
“身份”传输编码令牌已被删除。（第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)
块长度不包括块头和块尾中的八位字节计数。块扩展中不允许行折叠。（第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)
RFC 3986的段+查询组件用于定义请求目标，而不是RFC 1808中的abs_路径。请求目标的星号形式仅允许与OPTIONS方法一起使用。（第5.3节）
The term "Effective Request URI" has been introduced. (Section 5.5)
引入了术语“有效请求URI”。（第5.5节）
Gateways do not need to generate Via header fields anymore. (Section 5.7.1)
网关不再需要通过头字段生成。（第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)
明确了必须发送“关闭”连接选项的确切时间。此外，“逐跳”标题字段需要出现在连接标题字段中；仅仅因为它们在本规范中被定义为逐跳，并不免除它们。（第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)
升级头字段的语义现在在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)
转让编码的注册现在需要IETF审查（第8.4节）
This specification now defines the Upgrade Token Registry, previously defined in Section 7.2 of [RFC2817]. (Section 8.6)
本规范现在定义了升级令牌注册表，该注册表先前在[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）
BWS = OWS
BWS = OWS
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] )
Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
connection-option ] )
Content-Length = 1*DIGIT
Content-Length = 1*DIGIT
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
]
HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
Host = uri-host [ ":" port ]
HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
]
HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
Host = uri-host [ ":" port ]
OWS = *( SP / HTAB )
OWS = *( SP / HTAB )
RWS = 1*( SP / HTAB )
RWS = 1*( SP / HTAB )
TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] )
TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] )
URI-reference = <URI-reference, see [RFC3986], Section 4.1>
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
URI-reference = <URI-reference, see [RFC3986], Section 4.1>
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] )
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
comment ] ) ] )
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI
absolute-path = 1*( "/" segment )
asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
absolute-form = absolute-URI
absolute-path = 1*( "/" segment )
asterisk-form = "*"
authority = <authority, see [RFC3986], Section 3.2>
authority-form = authority
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-part CRLF
comment = "(" *( ctext / quoted-pair / comment ) ")"
connection-option = token
ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-data = 1*OCTET
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token / quoted-string
chunk-size = 1*HEXDIG
chunked-body = *chunk last-chunk trailer-part CRLF
comment = "(" *( ctext / quoted-pair / comment ) ")"
connection-option = token
ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-name = token
field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text
fragment = <fragment, see [RFC3986], Section 3.5>
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-name = token
field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text
fragment = <fragment, see [RFC3986], Section 3.5>
header-field = field-name ":" OWS field-value OWS
http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
fragment ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ]
header-field = field-name ":" OWS field-value OWS
http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
fragment ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ]
last-chunk = 1*"0" [ chunk-ext ] CRLF
last-chunk = 1*"0" [ chunk-ext ] CRLF
message-body = *OCTET
method = token
message-body = *OCTET
method = token
obs-fold = CRLF 1*( SP / HTAB )
obs-text = %x80-FF
origin-form = absolute-path [ "?" query ]
obs-fold = CRLF 1*( SP / HTAB )
obs-text = %x80-FF
origin-form = absolute-path [ "?" query ]
partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
port = <port, see [RFC3986], Section 3.2.3>
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2>
request-line = method SP request-target SP HTTP-version CRLF
request-target = origin-form / absolute-form / authority-form /
asterisk-form
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
reason-phrase = *( HTAB / SP / VCHAR / obs-text )
received-by = ( uri-host [ ":" port ] ) / pseudonym
received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [RFC3986], Section 4.2>
request-line = method SP request-target SP HTTP-version CRLF
request-target = origin-form / absolute-form / authority-form /
asterisk-form
scheme = <scheme, see [RFC3986], Section 3.1>
segment = <segment, see [RFC3986], Section 3.3>
start-line = request-line / status-line
status-code = 3DIGIT
status-line = HTTP-version SP status-code SP reason-phrase CRLF
scheme = <scheme, see [RFC3986], Section 3.1>
segment = <segment, see [RFC3986], Section 3.3>
start-line = request-line / status-line
status-code = 3DIGIT
status-line = HTTP-version SP status-code SP reason-phrase CRLF
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar
trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar
trailer-part = *( header-field CRLF )
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, see [RFC3986], Section 3.2.2>
uri-host = <host, see [RFC3986], Section 3.2.2>
Index
指数
A absolute-form (of request-target) 42 accelerator 10 application/http Media Type 63 asterisk-form (of request-target) 43 authoritative response 67 authority-form (of request-target) 42-43
绝对形式（请求目标）42加速器10应用程序/http媒体类型63星号形式（请求目标）43权威响应67权威形式（请求目标）42-43
B browser 7
B浏览器7
C cache 11 cacheable 12 captive portal 11 chunked (Coding Format) 28, 32, 36 client 7 close 51, 56 compress (Coding Format) 38 connection 7 Connection header field 51, 56 Content-Length header field 30
C缓存11可缓存12捕获入口11分块（编码格式）28、32、36客户端7关闭51、56压缩（编码格式）38连接7连接头字段51、56内容长度头字段30
D deflate (Coding Format) 38 Delimiters 27 downstream 10
D deflate（编码格式）38分隔符27下游10
E effective request URI 45
E有效请求URI 45
G gateway 10 Grammar absolute-form 42 absolute-path 16 absolute-URI 16 ALPHA 6 asterisk-form 41, 43 authority 16 authority-form 42-43 BWS 25 chunk 36 chunk-data 36 chunk-ext 36 chunk-ext-name 36
G网关10语法绝对表42绝对路径16绝对URI 16 ALPHA 6星号表41，43权限16权限表42-43 BWS 25数据块36数据块外部36数据块外部36数据块外部名称36
chunk-ext-val 36 chunk-size 36 chunked-body 36 comment 27 Connection 51 connection-option 51 Content-Length 30 CR 6 CRLF 6 ctext 27 CTL 6 DIGIT 6 DQUOTE 6 field-content 23 field-name 23, 40 field-value 23 field-vchar 23 fragment 16 header-field 23, 37 HEXDIG 6 Host 44 HTAB 6 HTTP-message 19 HTTP-name 14 http-URI 17 HTTP-version 14 https-URI 18 last-chunk 36 LF 6 message-body 28 method 21 obs-fold 23 obs-text 27 OCTET 6 origin-form 42 OWS 25 partial-URI 16 port 16 protocol-name 47 protocol-version 47 pseudonym 47 qdtext 27 query 16 quoted-pair 27 quoted-string 27 rank 39 reason-phrase 22 received-by 47
chunk ext val 36 chunk size 36 chunk body 36 comment 27 Connection 51 Connection option 51 Content Length 30 CR 6 CRLF 6 ctext 27 CTL 6 digital 6 DQUOTE 6 field Content 23 field name 23，40 field value 23 field vchar 23 fragment 16 header field 23，37 HEXDIG 6主机44 HTAB 6 HTTP消息19 HTTP名称14 HTTP URI 17 HTTP版本14 https URI 18最后一块36 LF 6消息正文28方法21 obs折叠23 obs文本27八位组6原始表单42 OWS 25部分URI 16端口16协议名称47协议版本47假名47 qdtext 27查询16引号对27引号字符串27秩39原因短语2247人收到
received-protocol 47 request-line 21 request-target 41 RWS 25 scheme 16 segment 16 SP 6 start-line 21 status-code 22 status-line 22 t-codings 39 t-ranking 39 tchar 27 TE 39 token 27 Trailer 40 trailer-part 37 transfer-coding 35 Transfer-Encoding 28 transfer-extension 35 transfer-parameter 35 Upgrade 57 uri-host 16 URI-reference 16 VCHAR 6 Via 47 gzip (Coding Format) 39
收到协议47请求行21请求目标41 RWS 25方案16段16 SP 6起始行21状态代码22状态行22 t编码39 t排名39 tchar 27 TE 39令牌27拖车40拖车部分37传输编码35传输编码28传输扩展35传输参数35升级57 uri主机16 uri参考16 VCHAR 6通过47gzip（编码格式）39
H header field 19 header section 19 headers 19 Host header field 44 http URI scheme 17 https URI scheme 17 I inbound 9 interception proxy 11 intermediary 9
H头字段19头部分19头19主机头字段44 http URI方案17 https URI方案17 I入站9拦截代理11中间层9
M Media Type application/http 63 message/http 62 message 7 message/http Media Type 62 method 21
M媒体类型应用程序/http 63消息/http 62消息7消息/http媒体类型62方法21
N non-transforming proxy 49
N非转换代理49
O origin server 7 origin-form (of request-target) 42 outbound 10
O原始服务器7原始表单（请求目标）42出站10
P phishing 67 proxy 10
网络钓鱼67代理10
R recipient 7 request 7 request-target 21 resource 16 response 7 reverse proxy 10
R接收方7请求7请求目标21资源16响应7反向代理10
S sender 7 server 7 spider 7
S发送方7服务器7蜘蛛7
T target resource 40 target URI 40 TE header field 39 Trailer header field 40 Transfer-Encoding header field 28 transforming proxy 49 transparent proxy 11 tunnel 10
T目标资源40目标URI 40 TE头字段39拖车头字段40传输编码头字段28转换代理49透明代理11隧道10
U Upgrade header field 57 upstream 9 URI scheme http 17 https 17 user agent 7
U Upgrade header字段57上游9 URI方案http 17 https 17用户代理7
V Via header field 47
V通过标题字段47
Authors' Addresses
作者地址
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Roy T.Fielding（编辑）美国加利福尼亚州圣何塞公园大道345号Adobe系统公司，邮编95110
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/