Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7231 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7231 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
超文本传输协议（HTTP/1.1）：语义和内容
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.
超文本传输协议（HTTP）是用于分布式、协作式超文本信息系统的无状态应用程序级协议。本文档定义了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/rfc7231.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7231.
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 ....................................................6
1.1. Conformance and Error Handling .............................6
1.2. Syntax Notation ............................................6
2. Resources .......................................................7
3. Representations .................................................7
3.1. Representation Metadata ....................................8
3.1.1. Processing Representation Data ......................8
3.1.2. Encoding for Compression or Integrity ..............11
3.1.3. Audience Language ..................................13
3.1.4. Identification .....................................14
3.2. Representation Data .......................................17
3.3. Payload Semantics .........................................17
3.4. Content Negotiation .......................................18
3.4.1. Proactive Negotiation ..............................19
3.4.2. Reactive Negotiation ...............................20
4. Request Methods ................................................21
4.1. Overview ..................................................21
4.2. Common Method Properties ..................................22
4.2.1. Safe Methods .......................................22
4.2.2. Idempotent Methods .................................23
4.2.3. Cacheable Methods ..................................24
4.3. Method Definitions ........................................24
4.3.1. GET ................................................24
4.3.2. HEAD ...............................................25
4.3.3. POST ...............................................25
4.3.4. PUT ................................................26
4.3.5. DELETE .............................................29
4.3.6. CONNECT ............................................30
4.3.7. OPTIONS ............................................31
4.3.8. TRACE ..............................................32
5. Request Header Fields ..........................................33
5.1. Controls ..................................................33
5.1.1. Expect .............................................34
5.1.2. Max-Forwards .......................................36
5.2. Conditionals ..............................................36
5.3. Content Negotiation .......................................37
5.3.1. Quality Values .....................................37
5.3.2. Accept .............................................38
5.3.3. Accept-Charset .....................................40
5.3.4. Accept-Encoding ....................................41
5.3.5. Accept-Language ....................................42
5.4. Authentication Credentials ................................44
5.5. Request Context ...........................................44
5.5.1. From ...............................................44
5.5.2. Referer ............................................45
5.5.3. User-Agent .........................................46
1. Introduction ....................................................6
1.1. Conformance and Error Handling .............................6
1.2. Syntax Notation ............................................6
2. Resources .......................................................7
3. Representations .................................................7
3.1. Representation Metadata ....................................8
3.1.1. Processing Representation Data ......................8
3.1.2. Encoding for Compression or Integrity ..............11
3.1.3. Audience Language ..................................13
3.1.4. Identification .....................................14
3.2. Representation Data .......................................17
3.3. Payload Semantics .........................................17
3.4. Content Negotiation .......................................18
3.4.1. Proactive Negotiation ..............................19
3.4.2. Reactive Negotiation ...............................20
4. Request Methods ................................................21
4.1. Overview ..................................................21
4.2. Common Method Properties ..................................22
4.2.1. Safe Methods .......................................22
4.2.2. Idempotent Methods .................................23
4.2.3. Cacheable Methods ..................................24
4.3. Method Definitions ........................................24
4.3.1. GET ................................................24
4.3.2. HEAD ...............................................25
4.3.3. POST ...............................................25
4.3.4. PUT ................................................26
4.3.5. DELETE .............................................29
4.3.6. CONNECT ............................................30
4.3.7. OPTIONS ............................................31
4.3.8. TRACE ..............................................32
5. Request Header Fields ..........................................33
5.1. Controls ..................................................33
5.1.1. Expect .............................................34
5.1.2. Max-Forwards .......................................36
5.2. Conditionals ..............................................36
5.3. Content Negotiation .......................................37
5.3.1. Quality Values .....................................37
5.3.2. Accept .............................................38
5.3.3. Accept-Charset .....................................40
5.3.4. Accept-Encoding ....................................41
5.3.5. Accept-Language ....................................42
5.4. Authentication Credentials ................................44
5.5. Request Context ...........................................44
5.5.1. From ...............................................44
5.5.2. Referer ............................................45
5.5.3. User-Agent .........................................46
6. Response Status Codes ..........................................47
6.1. Overview of Status Codes ..................................48
6.2. Informational 1xx .........................................50
6.2.1. 100 Continue .......................................50
6.2.2. 101 Switching Protocols ............................50
6.3. Successful 2xx ............................................51
6.3.1. 200 OK .............................................51
6.3.2. 201 Created ........................................52
6.3.3. 202 Accepted .......................................52
6.3.4. 203 Non-Authoritative Information ..................52
6.3.5. 204 No Content .....................................53
6.3.6. 205 Reset Content ..................................53
6.4. Redirection 3xx ...........................................54
6.4.1. 300 Multiple Choices ...............................55
6.4.2. 301 Moved Permanently ..............................56
6.4.3. 302 Found ..........................................56
6.4.4. 303 See Other ......................................57
6.4.5. 305 Use Proxy ......................................58
6.4.6. 306 (Unused) .......................................58
6.4.7. 307 Temporary Redirect .............................58
6.5. Client Error 4xx ..........................................58
6.5.1. 400 Bad Request ....................................58
6.5.2. 402 Payment Required ...............................59
6.5.3. 403 Forbidden ......................................59
6.5.4. 404 Not Found ......................................59
6.5.5. 405 Method Not Allowed .............................59
6.5.6. 406 Not Acceptable .................................60
6.5.7. 408 Request Timeout ................................60
6.5.8. 409 Conflict .......................................60
6.5.9. 410 Gone ...........................................60
6.5.10. 411 Length Required ...............................61
6.5.11. 413 Payload Too Large .............................61
6.5.12. 414 URI Too Long ..................................61
6.5.13. 415 Unsupported Media Type ........................62
6.5.14. 417 Expectation Failed ............................62
6.5.15. 426 Upgrade Required ..............................62
6.6. Server Error 5xx ..........................................62
6.6.1. 500 Internal Server Error ..........................63
6.6.2. 501 Not Implemented ................................63
6.6.3. 502 Bad Gateway ....................................63
6.6.4. 503 Service Unavailable ............................63
6.6.5. 504 Gateway Timeout ................................63
6.6.6. 505 HTTP Version Not Supported .....................64
7. Response Header Fields .........................................64
7.1. Control Data ..............................................64
ed 7.1.1. Origination Date ...................................65
7.1.2. Location ...........................................68
7.1.3. Retry-After ........................................69
6. Response Status Codes ..........................................47
6.1. Overview of Status Codes ..................................48
6.2. Informational 1xx .........................................50
6.2.1. 100 Continue .......................................50
6.2.2. 101 Switching Protocols ............................50
6.3. Successful 2xx ............................................51
6.3.1. 200 OK .............................................51
6.3.2. 201 Created ........................................52
6.3.3. 202 Accepted .......................................52
6.3.4. 203 Non-Authoritative Information ..................52
6.3.5. 204 No Content .....................................53
6.3.6. 205 Reset Content ..................................53
6.4. Redirection 3xx ...........................................54
6.4.1. 300 Multiple Choices ...............................55
6.4.2. 301 Moved Permanently ..............................56
6.4.3. 302 Found ..........................................56
6.4.4. 303 See Other ......................................57
6.4.5. 305 Use Proxy ......................................58
6.4.6. 306 (Unused) .......................................58
6.4.7. 307 Temporary Redirect .............................58
6.5. Client Error 4xx ..........................................58
6.5.1. 400 Bad Request ....................................58
6.5.2. 402 Payment Required ...............................59
6.5.3. 403 Forbidden ......................................59
6.5.4. 404 Not Found ......................................59
6.5.5. 405 Method Not Allowed .............................59
6.5.6. 406 Not Acceptable .................................60
6.5.7. 408 Request Timeout ................................60
6.5.8. 409 Conflict .......................................60
6.5.9. 410 Gone ...........................................60
6.5.10. 411 Length Required ...............................61
6.5.11. 413 Payload Too Large .............................61
6.5.12. 414 URI Too Long ..................................61
6.5.13. 415 Unsupported Media Type ........................62
6.5.14. 417 Expectation Failed ............................62
6.5.15. 426 Upgrade Required ..............................62
6.6. Server Error 5xx ..........................................62
6.6.1. 500 Internal Server Error ..........................63
6.6.2. 501 Not Implemented ................................63
6.6.3. 502 Bad Gateway ....................................63
6.6.4. 503 Service Unavailable ............................63
6.6.5. 504 Gateway Timeout ................................63
6.6.6. 505 HTTP Version Not Supported .....................64
7. Response Header Fields .........................................64
7.1. Control Data ..............................................64
ed 7.1.1. Origination Date ...................................65
7.1.2. Location ...........................................68
7.1.3. Retry-After ........................................69
7.1.4. Vary ...............................................70
7.2. Validator Header Fields ...................................71
7.3. Authentication Challenges .................................72
7.4. Response Context ..........................................72
7.4.1. Allow ..............................................72
7.4.2. Server .............................................73
8. IANA Considerations ............................................73
8.1. Method Registry ...........................................73
8.1.1. Procedure ..........................................74
8.1.2. Considerations for New Methods .....................74
8.1.3. Registrations ......................................75
8.2. Status Code Registry ......................................75
8.2.1. Procedure ..........................................75
8.2.2. Considerations for New Status Codes ................76
8.2.3. Registrations ......................................76
8.3. Header Field Registry .....................................77
8.3.1. Considerations for New Header Fields ...............78
8.3.2. Registrations ......................................80
8.4. Content Coding Registry ...................................81
8.4.1. Procedure ..........................................81
8.4.2. Registrations ......................................81
9. Security Considerations ........................................81
9.1. Attacks Based on File and Path Names ......................82
9.2. Attacks Based on Command, Code, or Query Injection ........82
9.3. Disclosure of Personal Information ........................83
9.4. Disclosure of Sensitive Information in URIs ...............83
9.5. Disclosure of Fragment after Redirects ....................84
9.6. Disclosure of Product Information .........................84
9.7. Browser Fingerprinting ....................................84
10. Acknowledgments ...............................................85
11. References ....................................................85
11.1. Normative References .....................................85
11.2. Informative References ...................................86
Appendix A. Differences between HTTP and MIME .....................89
A.1. MIME-Version ..............................................89
A.2. Conversion to Canonical Form ..............................89
A.3. Conversion of Date Formats ................................90
A.4. Conversion of Content-Encoding ............................90
A.5. Conversion of Content-Transfer-Encoding ...................90
A.6. MHTML and Line Length Limitations .........................90
Appendix B. Changes from RFC 2616 .................................91
Appendix C. Imported ABNF .........................................93
Appendix D. Collected ABNF ........................................94
Index .............................................................97
7.1.4. Vary ...............................................70
7.2. Validator Header Fields ...................................71
7.3. Authentication Challenges .................................72
7.4. Response Context ..........................................72
7.4.1. Allow ..............................................72
7.4.2. Server .............................................73
8. IANA Considerations ............................................73
8.1. Method Registry ...........................................73
8.1.1. Procedure ..........................................74
8.1.2. Considerations for New Methods .....................74
8.1.3. Registrations ......................................75
8.2. Status Code Registry ......................................75
8.2.1. Procedure ..........................................75
8.2.2. Considerations for New Status Codes ................76
8.2.3. Registrations ......................................76
8.3. Header Field Registry .....................................77
8.3.1. Considerations for New Header Fields ...............78
8.3.2. Registrations ......................................80
8.4. Content Coding Registry ...................................81
8.4.1. Procedure ..........................................81
8.4.2. Registrations ......................................81
9. Security Considerations ........................................81
9.1. Attacks Based on File and Path Names ......................82
9.2. Attacks Based on Command, Code, or Query Injection ........82
9.3. Disclosure of Personal Information ........................83
9.4. Disclosure of Sensitive Information in URIs ...............83
9.5. Disclosure of Fragment after Redirects ....................84
9.6. Disclosure of Product Information .........................84
9.7. Browser Fingerprinting ....................................84
10. Acknowledgments ...............................................85
11. References ....................................................85
11.1. Normative References .....................................85
11.2. Informative References ...................................86
Appendix A. Differences between HTTP and MIME .....................89
A.1. MIME-Version ..............................................89
A.2. Conversion to Canonical Form ..............................89
A.3. Conversion of Date Formats ................................90
A.4. Conversion of Content-Encoding ............................90
A.5. Conversion of Content-Transfer-Encoding ...................90
A.6. MHTML and Line Length Limitations .........................90
Appendix B. Changes from RFC 2616 .................................91
Appendix C. Imported ABNF .........................................93
Appendix D. Collected ABNF ........................................94
Index .............................................................97
Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in [RFC7230].
每个超文本传输协议（HTTP）消息要么是请求，要么是响应。服务器侦听请求的连接，解析接收到的每条消息，解释与已识别的请求目标相关的消息语义，并使用一条或多条响应消息响应该请求。客户机构造请求消息来传达特定的意图，检查收到的响应以查看意图是否执行，并确定如何解释结果。本文档根据[RFC7230]中定义的体系结构定义了HTTP/1.1请求和响应语义。
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (Section 3).
HTTP提供了一个统一的接口，用于通过操作和传输表示（第3节）与资源进行交互（第2节），而不管其类型、性质或实现如何。
HTTP semantics include the intentions defined by each request method (Section 4), extensions to those semantics that might be described in request header fields (Section 5), the meaning of status codes to indicate a machine-readable response (Section 6), and the meaning of other control data and resource metadata that might be given in response header fields (Section 7).
HTTP语义包括每个请求方法定义的意图（第4节）、对请求头字段中可能描述的语义的扩展（第5节）、指示机器可读响应的状态代码的含义（第6节），以及响应头字段中可能给出的其他控制数据和资源元数据的含义（第7节）。
This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "content negotiation" (Section 3.4).
本文档还定义了描述接收者如何解释有效负载的表示元数据、可能影响内容选择的请求头字段以及统称为“内容协商”的各种选择算法（第3.4节）。
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 of [RFC7230].
[RFC7230]第2.5节定义了与错误处理相关的一致性标准和注意事项。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix C describes rules imported from other documents. Appendix D shows the collected grammar with all list operators expanded to standard ABNF notation.
本规范使用[RFC7230]第7节中定义的[RFC5234]的增广巴科斯-诺尔形式（ABNF）符号和列表扩展，允许使用“#”运算符（类似于“*”运算符表示重复）对逗号分隔的列表进行紧凑定义。附录C描述了从其他文件导入的规则。附录D显示了收集的语法，所有列表运算符都扩展为标准ABNF表示法。
This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].
本规范使用[RFC6365]中定义的术语“字符”、“字符编码方案”、“字符集”和“协议元素”。
The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230].
HTTP请求的目标称为“资源”。HTTP不限制资源的性质；它仅仅定义了一个可能用于与资源交互的接口。每个资源由统一资源标识符（URI）标识，如[RFC7230]第2.7节所述。
When a client constructs an HTTP/1.1 request message, it sends the target URI in one of various forms, as defined in (Section 5.3 of [RFC7230]). When a request is received, the server reconstructs an effective request URI for the target resource (Section 5.5 of [RFC7230]).
当客户端构造HTTP/1.1请求消息时，它会以各种形式之一发送目标URI，如[RFC7230]的第5.3节所定义。当收到请求时，服务器将为目标资源重建有效的请求URI（RFC7230的第5.5节）。
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 4) and a few request-modifying header fields (Section 5). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in Section 4.2.1, the method semantics take precedence.
HTTP的一个设计目标是将资源标识与请求语义分离，这是通过将请求语义赋予请求方法（第4节）和几个请求修改头字段（第5节）实现的。如第4.2.1节所述，如果方法语义与URI本身隐含的任何语义之间存在冲突，则以方法语义为准。
Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation [REST].
考虑到资源可以是任何东西，并且HTTP提供的统一接口类似于一个窗口，通过该窗口，人们只能通过与另一方的某个独立参与者的消息通信来观察和处理这样的事情，因此需要一个抽象来表示（“代替”）在我们的通信中，该事物的当前或期望状态。这种抽象称为表示[REST]。
For the purposes of HTTP, a "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.
为了HTTP的目的，“表示”是旨在以可通过协议容易地通信的格式反映给定资源的过去、当前或期望状态的信息，该信息由一组表示元数据和可能无限的表示数据流组成。
An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a target resource. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on content negotiation. This "selected representation" is used to provide the
源服务器可以提供或能够生成多个表示，每个表示都旨在反映目标资源的当前状态。在这种情况下，源服务器使用某种算法选择其中一种最适用于给定请求的表示形式，通常基于内容协商。此“选定表示”用于提供
data and metadata for evaluating conditional requests [RFC7232] and constructing the payload for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1).
用于评估条件请求[RFC7232]并为要获取的200（正常）和304（未修改）响应构建有效负载的数据和元数据（第4.3.1节）。
Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.
表示标头字段提供有关表示的元数据。当消息包括有效负载正文时，表示标头字段描述如何解释有效负载正文中包含的表示数据。在对HEAD请求的响应中，representation header字段描述了表示数据，如果相同的请求是GET，则表示数据将被包含在有效负载主体中。
The following header fields convey representation metadata:
以下标题字段传递表示元数据：
+-------------------+-----------------+
| Header Field Name | Defined in... |
+-------------------+-----------------+
| Content-Type | Section 3.1.1.5 |
| Content-Encoding | Section 3.1.2.2 |
| Content-Language | Section 3.1.3.2 |
| Content-Location | Section 3.1.4.2 |
+-------------------+-----------------+
+-------------------+-----------------+
| Header Field Name | Defined in... |
+-------------------+-----------------+
| Content-Type | Section 3.1.1.5 |
| Content-Encoding | Section 3.1.2.2 |
| Content-Language | Section 3.1.3.2 |
| Content-Location | Section 3.1.4.2 |
+-------------------+-----------------+
HTTP uses Internet media types [RFC2046] in the Content-Type (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.
HTTP在内容类型（第3.1.1.5节）和接受（第5.3.2节）头字段中使用互联网媒体类型[RFC2046]，以提供开放和可扩展的数据类型和类型协商。媒体类型定义了数据格式和各种处理模型：如何根据接收数据的每个上下文处理数据。
media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token
media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token
The type/subtype MAY be followed by parameters in the form of name=value pairs.
类型/子类型后面可以是名称=值对形式的参数。
parameter = token "=" ( token / quoted-string )
parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.
类型、子类型和参数名称标记不区分大小写。参数值可能区分大小写，也可能不区分大小写，具体取决于参数名称的语义。参数的存在或不存在对媒体类型的处理可能很重要，这取决于媒体类型注册表中的定义。
A parameter value that matches the token production can be transmitted either as a token or within a quoted-string. The quoted and unquoted values are equivalent. For example, the following examples are all equivalent, but the first is preferred for consistency:
与令牌生产匹配的参数值可以作为令牌或在带引号的字符串中传输。带引号和不带引号的值是等效的。例如，以下示例都是等效的，但出于一致性考虑，首选第一个示例：
text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
Internet media types ought to be registered with IANA according to the procedures defined in [BCP13].
互联网媒体类型应按照[BCP13]中规定的程序向IANA注册。
Note: Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.
注意：与其他标题字段中的一些类似构造不同，媒体类型参数不允许在“=”字符周围使用空格（甚至“坏”空格）。
HTTP uses charset names to indicate or negotiate the character encoding scheme of a textual representation [RFC6365]. A charset is identified by a case-insensitive token.
HTTP使用字符集名称指示或协商文本表示的字符编码方案[RFC6365]。字符集由不区分大小写的标记标识。
charset = token
charset = token
Charset names ought to be registered in the IANA "Character Sets" registry (<http://www.iana.org/assignments/character-sets>) according to the procedures defined in [RFC2978].
字符集名称应该在IANA“字符集”注册表中注册(<http://www.iana.org/assignments/character-sets>)根据[RFC2978]中定义的程序。
Internet media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see Appendix A).
Internet媒体类型以规范形式注册，以便在具有各种本机编码格式的系统之间进行互操作。由于多用途Internet邮件扩展（MIME）[RFC2045]所描述的许多相同原因，通过HTTP选择或传输的表示应该是规范形式的。但是，电子邮件部署的性能特征（即，将消息存储并转发给对等方）与HTTP和Web（基于服务器的信息服务）的常见性能特征明显不同。此外，MIME为了与旧邮件传输协议兼容而提出的限制不适用于HTTP（见附录A）。
MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break. HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation. An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively. This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the payload body (e.g., header fields).
MIME的规范形式要求“text”类型的媒体子类型使用CRLF作为文本换行符。HTTP允许传输纯CR或LF单独表示换行符的文本媒体，而这种换行符在整个表示中是一致的。HTTP发送方可以在由CRLF、bare CR或bare LF组成的文本媒体中生成换行符，而接收方必须能够解析这些换行符。此外，HTTP中的文本媒体不限于分别使用八位字节13和10表示CR和LF的字符集。关于换行符的这种灵活性仅适用于已指定“文本”媒体类型的表示中的文本；它不适用于有效负载主体之外的“多部分”类型或HTTP元素（例如，头字段）。
If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded.
如果使用内容编码对表示进行编码，则在编码之前，基础数据应该采用上面定义的形式。
MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body. All multipart types share a common syntax, as defined in Section 5.1.1 of [RFC2046], and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts.
MIME提供了许多“多部分”类型——在单个消息体中封装一个或多个表示。所有多部分类型共享一个通用语法，如[RFC2046]第5.1.1节所定义，并包括一个边界参数作为媒体类型值的一部分。消息体本身是一个协议元素；发送方必须仅生成CRLF以表示身体部位之间的换行符。
HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by implementations that generate or process the payload. For example, the "multipart/form-data" type is often used for carrying form data in a request, as described in [RFC2388], and the "multipart/ byteranges" type is defined by this specification for use in some 206 (Partial Content) responses [RFC7233].
HTTP消息框架不使用多部分边界作为消息正文长度的指示器，尽管生成或处理负载的实现可能会使用它。例如，“多部分/表单数据”类型通常用于在请求中携带表单数据，如[RFC2388]中所述，“多部分/byteranges”类型由本规范定义，用于某些206（部分内容）响应[RFC7233]。
The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed in the message payload or the selected representation, as determined by the message semantics. The indicated media type defines both the data format and how that data is intended to be processed by a recipient, within the scope of the received message semantics, after any content codings indicated by Content-Encoding are decoded.
“Content Type”头字段指示关联表示的媒体类型：消息负载中包含的表示或由消息语义确定的选定表示。指示的媒体类型定义了数据格式以及在对内容编码指示的任何内容编码进行解码后，接收者将如何在接收到的消息语义范围内处理该数据。
Content-Type = media-type
Content-Type = media-type
Media types are defined in Section 3.1.1.1. An example of the field is
第3.1.1.1节定义了介质类型。该字段的一个示例是
Content-Type: text/html; charset=ISO-8859-4
Content-Type: text/html; charset=ISO-8859-4
A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.
生成包含有效负载正文的消息的发送方应在该消息中生成内容类型头字段，除非发送方不知道所附表示的预期媒体类型。如果内容类型标头字段不存在，则收件人可以假定媒体类型为“应用程序/八位字节流”（[RFC2046]，第4.5.1节），或者检查数据以确定其类型。
In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
实际上，资源所有者并不总是正确地配置其源服务器，以便为给定的表示提供正确的内容类型，结果是一些客户端将检查有效负载的内容并覆盖指定的类型。这样做的客户端可能得出错误的结论，这可能会暴露额外的安全风险（例如，“权限升级”）。此外，不可能通过检查数据格式来确定发送者的意图：许多数据格式匹配多个仅在处理语义上不同的媒体类型。鼓励实施者在使用时提供一种禁用此类“内容嗅探”的方法。
Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted directly, and only decoded by the final recipient.
内容编码值表示已经或可以应用于表示的编码转换。内容编码主要用于压缩或以其他方式有效转换表示，而不会丢失其底层媒体类型的标识，也不会丢失信息。通常，表示以编码形式存储，直接传输，仅由最终接收者解码。
content-coding = token
content-coding = token
All content-coding values are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as defined in Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) and Content-Encoding (Section 3.1.2.2) header fields.
所有内容编码值都不区分大小写，应在第8.4节定义的“HTTP内容编码注册表”中注册。它们用于接受编码（第5.3.4节）和内容编码（第3.1.2.2节）标题字段。
The following content-coding values are defined by this specification:
本规范定义了以下内容编码值：
compress (and x-compress): See Section 4.2.1 of [RFC7230].
压缩（和x压缩）：见[RFC7230]第4.2.1节。
deflate: See Section 4.2.2 of [RFC7230].
放气：见[RFC7230]第4.2.2节。
gzip (and x-gzip): See Section 4.2.3 of [RFC7230].
gzip（和x-gzip）：见[RFC7230]第4.2.3节。
The "Content-Encoding" header field indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type.
“内容编码”头字段指示除了媒体类型中固有的内容编码之外，哪些内容编码已应用于表示，因此必须应用哪些解码机制以获得由内容类型头字段引用的媒体类型中的数据。内容编码主要用于压缩表示的数据，而不会丢失其底层媒体类型的标识。
Content-Encoding = 1#content-coding
内容编码=1#内容编码
An example of its use is
其使用的一个例子是
Content-Encoding: gzip
内容编码：gzip
If one or more encodings have been applied to a representation, the sender that applied the encodings MUST generate a Content-Encoding header field that lists the content codings in the order in which they were applied. Additional information about the encoding parameters can be provided by other header fields not defined by this specification.
如果对表示应用了一个或多个编码，则应用编码的发送方必须生成一个内容编码头字段，该字段按应用的顺序列出内容编码。有关编码参数的附加信息可由本规范未定义的其他标题字段提供。
Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), the codings listed in Content-Encoding are a characteristic of the representation; the representation is defined in terms of the coded form, and all other metadata about the representation is about the coded form unless otherwise noted in the metadata definition. Typically, the representation is only decoded just prior to rendering or analogous usage.
与传输编码（RFC7230）第3.3.1节不同，内容编码中列出的编码是表示的一个特征；表示是根据编码形式定义的，除非元数据定义中另有说明，否则有关表示的所有其他元数据都是关于编码形式的。通常，仅在渲染或类似使用之前对表示进行解码。
If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin server might choose to publish the same data as multiple representations that differ only in whether the coding is defined as part of Content-Type
如果媒体类型包括固有的编码，例如始终压缩的数据格式，则即使该编码恰好是与内容编码之一相同的算法，也不会在内容编码中重述该编码。这种内容编码只有在出于某种奇怪的原因再次应用以形成表示时才会被列出。同样，源服务器可能会选择将相同的数据发布为多个表示形式，这些表示形式仅在编码是否定义为内容类型的一部分方面有所不同
or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
或内容编码，因为某些用户代理在处理每个响应时的行为不同（例如，打开“另存为…”对话框，而不是自动解压缩和呈现内容）。
An origin server MAY respond with a status code of 415 (Unsupported Media Type) if a representation in the request message has a content coding that is not acceptable.
如果请求消息中的表示具有不可接受的内容编码，则源服务器可以使用状态代码415（不支持的媒体类型）进行响应。
A language tag, as defined in [RFC5646], identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.
[RFC5646]中定义的语言标签标识了人类所说、所写或以其他方式传达的自然语言，用于与其他人类进行信息交流。计算机语言被明确排除在外。
HTTP uses language tags within the Accept-Language and Content-Language header fields. Accept-Language uses the broader language-range production defined in Section 5.3.5, whereas Content-Language uses the language-tag production defined below.
HTTP在Accept language和Content language标头字段中使用语言标记。Accept Language使用第5.3.5节中定义的更广泛的语言范围产品，而Content Language使用下面定义的语言标记产品。
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, each separated by a hyphen character ("-", %x2D). In most cases, a language tag consists of a primary language subtag that identifies a broad family of related languages (e.g., "en" = English), which is optionally followed by a series of subtags that refine or narrow that language's range (e.g., "en-CA" = the variety of English as communicated in Canada). Whitespace is not allowed within a language tag. Example tags include:
语言标记是一个或多个不区分大小写的子标记序列，每个子标记由连字符（“-”，%x2D）分隔。在大多数情况下，一个语言标记由一个主要语言子标记组成，该子标记标识了一个广泛的相关语言家族（例如，“en”=英语），该子标记后面可选地跟随一系列子标记，这些子标记细化或缩小了该语言的范围（例如，“en CA”=在加拿大交流的各种英语）。语言标记中不允许有空格。示例标记包括：
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
法国，欧洲，美国，es-419，亚利桑那州阿拉伯，x-pig-latin，man-Nkoo GN
See [RFC5646] for further information.
有关更多信息，请参阅[RFC5646]。
The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note that this might not be equivalent to all the languages used within the representation.
“内容语言”标题字段描述表示的预期受众的自然语言。请注意，这可能并不等同于表示中使用的所有语言。
Content-Language = 1#language-tag
内容语言=1#语言标记
Language tags are defined in Section 3.1.3.1. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the users' own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field is
第3.1.3.1节定义了语言标记。内容语言的主要目的是允许用户根据用户自己的首选语言识别和区分表示。因此，如果内容仅针对丹麦识字的观众，则适当的字段为
Content-Language: da
内容语言：da
If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.
如果未指定内容语言，则默认情况下，该内容适用于所有语言受众。这可能意味着发送者不认为它对任何自然语言是特定的，或者发送者不知道它打算使用哪种语言。
Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented simultaneously in the original Maori and English versions, would call for
针对面向多个受众的内容，可以列出多种语言。例如，同时以毛利语和英语原版呈现的《怀唐伊条约》的译本将要求
Content-Language: mi, en
内容语言：mi，en
However, just because multiple languages are present within a representation does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
然而，仅仅因为一个表示中存在多种语言并不意味着它是针对多种语言的受众的。一个例子是初学者语言入门，例如“拉丁语第一课”，这显然是为了让懂英语的观众使用。在这种情况下，内容语言将正确地仅包括“en”。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
内容语言可以应用于任何媒体类型——它不限于文本文档。
When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation.
当在消息有效负载中传输完整或部分表示时，通常希望发送方提供或接收方确定与该表示相对应的资源的标识符。
For a request message:
对于请求消息：
o If the request has a Content-Location header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification). The information might still be useful for revision history links.
o 如果请求具有内容位置头字段，则发送方断言有效负载是由内容位置字段值标识的资源的表示。但是，除非可以通过其他方式（本规范未定义）验证，否则这种断言是不可信的。这些信息对于修订历史记录链接可能仍然有用。
o Otherwise, the payload is unidentified.
o 否则，有效载荷无法识别。
For a response message, the following rules are applied in order until a match is found:
对于响应消息，将按顺序应用以下规则，直到找到匹配项：
1. If the request method is GET or HEAD and the response status code is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not Modified), the payload is a representation of the resource identified by the effective request URI (Section 5.5 of [RFC7230]).
1. 如果请求方法为GET或HEAD，且响应状态代码为200（确定）、204（无内容）、206（部分内容）或304（未修改），则有效负载是由有效请求URI（RFC7230的第5.5节）标识的资源的表示。
2. If the request method is GET or HEAD and the response status code is 203 (Non-Authoritative Information), the payload is a potentially modified or enhanced representation of the target resource as provided by an intermediary.
2. 如果请求方法是GET或HEAD，并且响应状态代码是203（非权威信息），则有效负载是由中介提供的目标资源的潜在修改或增强的表示。
3. If the response has a Content-Location header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation of the resource identified by the effective request URI.
3. 如果响应具有内容位置头字段，并且其字段值是对与有效请求URI相同的URI的引用，则有效负载是由有效请求URI标识的资源的表示。
4. If the response has a Content-Location header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification).
4. 如果响应具有内容位置报头字段，并且其字段值是对不同于有效请求URI的URI的引用，则发送方断言有效负载是由内容位置字段值标识的资源的表示。但是，除非可以通过其他方式（本规范未定义）验证，否则这种断言是不可信的。
5. Otherwise, the payload is unidentified.
5. 否则，有效载荷无法识别。
The "Content-Location" header field references a URI that can be used as an identifier for a specific resource corresponding to the representation in this message's payload. In other words, if one were to perform a GET request on this URI at the time of this message's generation, then a 200 (OK) response would contain the same representation that is enclosed as payload in this message.
“Content Location”头字段引用一个URI，该URI可用作与此消息有效负载中的表示相对应的特定资源的标识符。换句话说，如果在生成此消息时对该URI执行GET请求，那么200（OK）响应将包含与此消息中的有效负载相同的表示。
Content-Location = absolute-URI / partial-URI
Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective Request URI (Section 5.5 of [RFC7230]). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME body parts in Section 4 of [RFC2557]. However, its appearance in an HTTP message has some special implications for HTTP recipients.
内容位置值不能替代有效的请求URI（RFC7230的第5.5节）。它是表示元数据。它的语法和语义与[RFC2557]第4节中为MIME主体部分定义的同名标题字段相同。然而，它在HTTP消息中的出现对HTTP收件人有一些特殊的含义。
If Content-Location is included in a 2xx (Successful) response message and its value refers (after conversion to absolute form) to a URI that is the same as the effective request URI, then the recipient MAY consider the payload to be a current representation of that resource at the time indicated by the message origination date. For a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the same as the default semantics when no Content-Location is provided by the server. For a state-changing request like PUT (Section 4.3.4) or POST (Section 4.3.3), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the need for a subsequent GET request.
如果内容位置包含在2XX（成功）响应消息中，并且其值指（转换为绝对形式）到与有效请求URI相同的URI，则接收方可以认为有效载荷是在消息始发日期指示的时间上该资源的当前表示。对于GET（第4.3.1节）或HEAD（第4.3.2节）请求，这与服务器未提供内容位置时的默认语义相同。对于状态更改请求，如PUT（第4.3.4节）或POST（第4.3.3节），这意味着服务器的响应包含该资源的新表示形式，从而将其与可能仅报告操作的表示形式区分开来（例如，“它工作了！”）。这允许创作应用程序更新其本地副本，而无需后续GET请求。
If Content-Location is included in a 2xx (Successful) response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP.
如果内容位置包含在2xx（成功）响应消息中，且其字段值引用的URI与有效请求URI不同，则源服务器声明该URI是对应于所附表示的不同资源的标识符。只有当两个标识符共享同一个资源所有者（不能通过HTTP以编程方式确定）时，才能信任这样的声明。
o For a response to a GET or HEAD request, this is an indication that the effective request URI refers to a resource that is subject to content negotiation and the Content-Location field-value is a more specific identifier for the selected representation.
o 对于GET或HEAD请求的响应，这表示有效请求URI指的是要进行内容协商的资源，并且内容位置字段值是所选表示的更具体标识符。
o For a 201 (Created) response to a state-changing method, a Content-Location field-value that is identical to the Location field-value indicates that this payload is a current representation of the newly created resource.
o 对于对状态改变方法的201（创建的）响应，与位置字段值相同的内容位置字段值指示该有效载荷是新创建的资源的当前表示。
o Otherwise, such a Content-Location indicates that this payload is a representation reporting on the requested action's status and that the same report is available (for future access with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as the payload of the 200 (OK) response; the Content-Location field-value provides an identifier for retrieving a copy of that same receipt in the future.
o 否则，这样的内容位置指示此有效负载是报告请求的操作状态的表示，并且相同的报告在给定URI处可用（用于将来使用GET进行访问）。例如，通过POST请求进行的购买交易可以包括收据文档作为200（OK）响应的有效载荷；内容位置字段值提供了一个标识符，用于将来检索同一收据的副本。
A user agent that sends Content-Location in a request message is stating that its value refers to where the user agent originally obtained the content of the enclosed representation (prior to any modifications made by that user agent). In other words, the user agent is providing a back link to the source of the original representation.
在请求消息中发送内容位置的用户代理声明其值指的是用户代理最初获取所附表示的内容的位置（在该用户代理进行任何修改之前）。换句话说，用户代理提供了到原始表示源的反向链接。
An origin server that receives a Content-Location field in a request message MUST treat the information as transitory request context rather than as metadata to be saved verbatim as part of the representation. An origin server MAY use that context to guide in processing the request or to save it for other uses, such as within source links or versioning metadata. However, an origin server MUST NOT use such context information to alter the request semantics.
在请求消息中接收内容位置字段的源服务器必须将该信息视为临时请求上下文，而不是作为元数据，以便作为表示的一部分逐字保存。源服务器可以使用该上下文来指导处理请求或将其保存以供其他用途，例如在源链接或版本控制元数据中。但是，源服务器不得使用此类上下文信息来更改请求语义。
For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI.
例如，如果客户机对协商资源发出PUT请求，并且源服务器接受该PUT（无重定向），则该资源的新状态应与该PUT中提供的表示一致；内容位置不能用作反向内容选择标识符的形式，以仅更新一个协商表示。如果用户代理想要后一种语义，它会将PUT直接应用于内容位置URI。
The representation data associated with an HTTP message is either provided as the payload body of the message or referred to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by the representation metadata header fields.
与HTTP消息关联的表示数据要么作为消息的有效负载主体提供，要么由消息语义和有效请求URI引用。表示数据的格式和编码由表示元数据标头字段定义。
The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
表示数据的数据类型通过标题字段Content type和Content Encoding确定。这些定义了两层有序编码模型：
representation-data := Content-Encoding( Content-Type( bits ) )
representation-data := Content-Encoding( Content-Type( bits ) )
Some HTTP messages transfer a complete or partial representation as the message "payload". In some cases, a payload might contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s) of the representation data (e.g., the 206 (Partial Content) status code).
一些HTTP消息将完整或部分表示形式作为消息“有效负载”进行传输。在某些情况下，有效载荷可能仅包含相关表示的报头字段（例如，对报头的响应）或仅包含表示数据的某些部分（例如，206（部分内容）状态代码）。
The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of a PUT request (Section 4.3.4) represents the desired state of the target resource if the request is successfully applied, whereas a representation in the payload of a POST request (Section 4.3.3) represents information to be processed by the target resource.
请求中有效负载的用途由方法语义定义。例如，PUT请求有效负载中的表示（第4.3.4节）表示成功应用请求时目标资源的期望状态，而POST请求有效负载中的表示（第4.3.3节）表示目标资源要处理的信息。
In a response, the payload's purpose is defined by both the request method and the response status code. For example, the payload of a 200 (OK) response to GET (Section 4.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 7.1.1.2), whereas the payload of the same status code in a response to POST might represent either the processing result or the new state of the target resource after applying the processing. Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.
在响应中，有效负载的用途由请求方法和响应状态代码定义。例如，GET的200（OK）响应的有效载荷（第4.3.1节）表示在消息发起日期（第7.1.1.2节）观察到的目标资源的当前状态，然而，POST响应中相同状态代码的有效负载可能表示处理结果或应用处理后目标资源的新状态。带有错误状态代码的响应消息通常包含表示错误条件的有效负载，以便它描述错误状态以及建议下一步如何解决该错误。
Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
专门描述有效载荷而非相关表示的报头字段称为“有效载荷报头字段”。由于有效负载头字段对消息解析的影响，在本规范的其他部分中定义了有效负载头字段。
+-------------------+----------------------------+
| Header Field Name | Defined in... |
+-------------------+----------------------------+
| Content-Length | Section 3.3.2 of [RFC7230] |
| Content-Range | Section 4.2 of [RFC7233] |
| Trailer | Section 4.4 of [RFC7230] |
| Transfer-Encoding | Section 3.3.1 of [RFC7230] |
+-------------------+----------------------------+
+-------------------+----------------------------+
| Header Field Name | Defined in... |
+-------------------+----------------------------+
| Content-Length | Section 3.3.2 of [RFC7230] |
| Content-Range | Section 4.2 of [RFC7233] |
| Trailer | Section 4.4 of [RFC7230] |
| Transfer-Encoding | Section 3.3.1 of [RFC7230] |
+-------------------+----------------------------+
When responses convey payload information, whether indicating a success or an error, the origin server often has different ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or user agents might have differing capabilities, characteristics, or preferences that could influence which representation, among those available, would be best to deliver. For this reason, HTTP provides mechanisms for content negotiation.
当响应传递有效负载信息时，无论指示成功还是错误，源服务器通常有不同的方式来表示该信息；例如，使用不同的格式、语言或编码。类似地，不同的用户或用户代理可能具有不同的功能、特征或偏好，这可能会影响可用表示中最适合提供的表示。因此，HTTP提供了内容协商机制。
This specification defines two patterns of content negotiation that can be made visible within the protocol: "proactive", where the server selects the representation based upon the user agent's stated preferences, and "reactive" negotiation, where the server provides a list of representations for the user agent to choose from. Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" ([RFC2295]), where content
本规范定义了两种可在协议中显示的内容协商模式：“主动式”，其中服务器根据用户代理声明的首选项选择表示；以及“反应式”协商，其中服务器提供表示列表供用户代理选择。内容协商的其他模式包括“条件内容”，其中表示由基于用户代理参数选择性呈现的多个部分组成，“活动内容”，其中表示包含基于用户代理特征发出附加（更具体）请求的脚本，以及“透明内容协商”（[RFC2295]），其中
selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in applicability and practicality.
选择由中间人执行。这些模式并不是相互排斥的，每种模式在适用性和实用性方面都有权衡。
Note that, in all cases, HTTP is not aware of the resource semantics. The consistency with which an origin server responds to requests, over time and over the varying dimensions of content negotiation, and thus the "sameness" of a resource's observed representations over time, is determined entirely by whatever entity or algorithm selects or generates those responses. HTTP pays no attention to the man behind the curtain.
注意，在所有情况下，HTTP都不知道资源语义。源服务器随时间和内容协商的不同维度响应请求的一致性，以及随时间观察到的资源表示的“相同性”，完全取决于选择或生成这些响应的实体或算法。HTTP不注意幕后的人。
When content negotiation preferences are sent by the user agent in a request to encourage an algorithm located at the server to select the preferred representation, it is called proactive negotiation (a.k.a., server-driven negotiation). Selection is based on the available representations for a response (the dimensions over which it might vary, such as language, content-coding, etc.) compared to various information supplied in the request, including both the explicit negotiation fields of Section 5.3 and implicit characteristics, such as the client's network address or parts of the User-Agent field.
当用户代理在请求中发送内容协商首选项以鼓励位于服务器的算法选择首选表示时，称为主动协商（又称服务器驱动协商）。与请求中提供的各种信息（包括第5.3节的明确协商字段和隐含特征）相比，选择基于响应的可用表示（其可能变化的维度，如语言、内容编码等），例如客户端的网络地址或部分用户代理字段。
Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to a user agent, or when the server desires to send its "best guess" to the user agent along with the first response (hoping to avoid the round trip delay of a subsequent request if the "best guess" is good enough for the user). In order to improve the server's guess, a user agent MAY send request header fields that describe its preferences.
当用于从可用表示中进行选择的算法难以向用户代理描述时，或者当服务器希望将其“最佳猜测”与第一个响应一起发送给用户代理时（希望在“最佳猜测”发生时避免后续请求的往返延迟），主动协商是有利的对用户来说已经足够好了）。为了改进服务器的猜测，用户代理可以发送描述其首选项的请求头字段。
Proactive negotiation has serious disadvantages:
积极主动的谈判有严重的缺点：
o It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?);
o 服务器不可能准确地确定对任何给定用户来说什么可能是“最好的”，因为这需要完全了解用户代理的功能和响应的预期用途（例如，用户希望在屏幕上查看还是在纸上打印？）；
o Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential risk to the user's privacy;
o 让用户代理在每个请求中描述其功能既可能非常低效（考虑到只有一小部分响应具有多个表示），也可能对用户隐私造成潜在风险；
o It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
o 它使源服务器的实现和生成请求响应的算法复杂化；和
o It limits the reusability of responses for shared caching.
o 它限制了共享缓存响应的可重用性。
A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response.
用户代理不能依赖于始终遵守主动协商首选项，因为源服务器可能不会对请求的资源实施主动协商，或者可能决定发送不符合用户代理首选项的响应比发送406（不可接受）响应更好。
A Vary header field (Section 7.1.4) is often sent in a response subject to proactive negotiation to indicate what parts of the request information were used in the selection algorithm.
Vary header字段（第7.1.4节）通常在接受主动协商的响应中发送，以指示在选择算法中使用了请求信息的哪些部分。
With reactive negotiation (a.k.a., agent-driven negotiation), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations. If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response. Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu.
对于反应式协商（也称为代理驱动的协商），用户代理在收到来自原始服务器的初始响应（其中包含用于替代表示的资源列表）后，选择最佳响应表示（无论状态代码如何）。如果用户代理对初始响应表示不满意，它可以对基于列表中包括的元数据选择的一个或多个备选资源执行GET请求，以获得该响应的不同形式的表示。备选方案的选择可以由用户代理自动执行，也可以由用户从生成的（可能是超文本）菜单中选择手动执行。
Note that the above refers to representations of the response, in general, not representations of the resource. The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a 200 (OK) response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a 300 (Multiple Choices) response to a GET request).
注意，上面提到的通常是响应的表示，而不是资源的表示。如果提供这些备选方案的响应具有作为目标资源的表示的语义（例如，对GET请求的200（OK）响应），则备选方案表示仅被视为目标资源的表示或者具有为目标资源提供指向替代表示的链接的语义（例如，对GET请求的300（多选）响应）。
A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred. For example, the alternatives listed in responses with the 300 (Multiple Choices) and 406 (Not Acceptable) status codes include information about the available representations so that the user or user agent can react by making a selection.
服务器可能选择不发送初始表示，而不发送备选方案列表，从而表明用户代理的反应式协商是首选。例如，在具有300（多项选择）和406（不可接受）状态代码的响应中列出的备选方案包括关于可用表示的信息，以便用户或用户代理可以通过作出选择来作出反应。
Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage.
当响应在常用维度（如类型、语言或编码）上不同时，当源服务器无法通过检查请求来确定用户代理的能力时，以及通常当使用公共缓存来分配服务器负载和减少网络使用时，反应式协商是有利的。
Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation. Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension.
反应式协商的缺点是向用户代理发送替代列表，如果在报头部分中发送，则会降低用户感知的延迟，并且需要第二个请求来获得替代表示。此外，本规范未定义支持自动选择的机制，尽管它并不阻止将此类机制开发为扩展。
The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.
请求方法令牌是请求语义的主要来源；它指出了客户提出此请求的目的以及客户对成功结果的期望。
The request method's semantics might be further specialized by the semantics of some header fields when present in a request (Section 5) if those additional semantics do not conflict with the method. For example, a client can send conditional request header fields (Section 5.2) to make the requested action conditional on the current state of the target resource ([RFC7232]).
如果请求方法的语义与方法不冲突，则请求方法的语义可以通过请求中某些头字段的语义（第5节）进一步专门化。例如，客户机可以发送条件请求头字段（第5.2节），使请求的操作以目标资源的当前状态（[RFC7232]）为条件。
method = token
method = token
HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would apply semantics. The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names.
HTTP最初被设计成可以作为分布式对象系统的接口使用。请求方法被设想为对目标资源应用语义，其方式与对已识别对象调用已定义的方法应用语义的方式大致相同。方法令牌区分大小写，因为它可以用作具有区分大小写方法名称的基于对象的系统的网关。
Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide for better visibility and reuse in network-based systems [REST]. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed.
与分布式对象不同，HTTP中的标准化请求方法不是特定于资源的，因为统一接口在基于网络的系统中提供了更好的可视性和重用性[REST]。一旦定义，标准化方法在应用于任何资源时应该具有相同的语义，尽管每个资源自己决定这些语义是实现的还是允许的。
This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. By convention, standardized methods are defined in all-uppercase US-ASCII letters.
本规范定义了HTTP中常用的许多标准化方法，如下表所示。按照惯例，标准化方法以所有大写US-ASCII字母定义。
+---------+-------------------------------------------------+-------+
| Method | Description | Sec. |
+---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 4.3.1 |
| | resource. | |
| HEAD | Same as GET, but only transfer the status line | 4.3.2 |
| | and header section. | |
| POST | Perform resource-specific processing on the | 4.3.3 |
| | request payload. | |
| PUT | Replace all current representations of the | 4.3.4 |
| | target resource with the request payload. | |
| DELETE | Remove all current representations of the | 4.3.5 |
| | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 4.3.6 |
| | the target resource. | |
| OPTIONS | Describe the communication options for the | 4.3.7 |
| | target resource. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | |
+---------+-------------------------------------------------+-------+
+---------+-------------------------------------------------+-------+
| Method | Description | Sec. |
+---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 4.3.1 |
| | resource. | |
| HEAD | Same as GET, but only transfer the status line | 4.3.2 |
| | and header section. | |
| POST | Perform resource-specific processing on the | 4.3.3 |
| | request payload. | |
| PUT | Replace all current representations of the | 4.3.4 |
| | target resource with the request payload. | |
| DELETE | Remove all current representations of the | 4.3.5 |
| | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 4.3.6 |
| | the target resource. | |
| OPTIONS | Describe the communication options for the | 4.3.7 |
| | target resource. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | |
+---------+-------------------------------------------------+-------+
All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.
所有通用服务器必须支持GET和HEAD方法。所有其他方法都是可选的。
Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry" maintained by IANA, as defined in Section 8.1.
本规范范围之外的其他方法已经标准化，可用于HTTP。所有此类方法应在IANA维护的“超文本传输协议（HTTP）方法注册表”中注册，如第8.1节所定义。
The set of methods allowed by a target resource can be listed in an Allow header field (Section 7.4.1). However, the set of allowed methods can change dynamically. When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code. When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.
目标资源允许的方法集可以在允许标头字段中列出（第7.4.1节）。但是，允许的方法集可以动态更改。当接收到源服务器无法识别或未实现的请求方法时，源服务器应使用501（未实现）状态代码进行响应。当接收到源服务器已知但目标资源不允许的请求方法时，源服务器应使用405（不允许的方法）状态代码进行响应。
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
如果请求方法定义的语义本质上是只读的，那么它们被认为是“安全的”；i、 例如，客户机不请求也不期望源服务器上的任何状态更改，因为对目标资源应用了安全方法。同样，合理使用安全方法也不会对源服务器造成任何伤害、财产损失或异常负担。
This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.
安全方法的这种定义并不阻止实现包含潜在有害的行为、不完全只读的行为或调用安全方法时产生副作用的行为。然而，重要的是，客户没有要求额外的行为，因此不能对此负责。例如，大多数服务器在每次响应完成时都会附加请求信息以访问日志文件，而不管采用何种方法，这被认为是安全的，即使日志存储可能已满并导致服务器崩溃。同样，通过选择网络广告发起的安全请求通常会产生向广告账户收费的副作用。
Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
在本规范定义的请求方法中，GET、HEAD、OPTIONS和TRACE方法被定义为安全的。
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
区分安全方法和不安全方法的目的是允许自动检索过程（spider）和缓存性能优化（预取）在不担心造成伤害的情况下工作。此外，它允许用户代理在处理可能不受信任的内容时对不安全方法的自动使用应用适当的约束。
A user agent SHOULD distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware of an unsafe action before it is requested.
当向用户呈现潜在操作时，用户代理应区分安全方法和不安全方法，以便在请求之前让用户知道不安全操作。
When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.
当资源的构造使得有效请求URI中的参数具有选择操作的效果时，资源所有者有责任确保操作与请求方法语义一致。例如，基于Web的内容编辑软件通常在查询参数内使用操作，例如“page？do=delete”。如果此类资源的目的是执行不安全的操作，则当使用安全请求方法访问该操作时，资源所有者必须禁用或不允许该操作。如果不这样做，当自动化进程为了链接维护、预取、构建搜索索引等而对每个URI引用执行GET时，将导致不幸的副作用。
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
如果使用请求方法的多个相同请求对服务器的预期效果与单个此类请求的效果相同，则该请求方法被视为“幂等”。在本规范定义的请求方法中，PUT、DELETE和safe请求方法是幂等的。
Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.
与safe的定义一样，幂等属性仅适用于用户请求的内容；服务器可以单独记录每个请求，保留修订控制历史记录，或者为每个幂等请求实现其他非幂等副作用。
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
区分幂等方法是因为如果在客户端能够读取服务器响应之前发生通信故障，请求可以自动重复。例如，如果客户端发送PUT请求，并且在收到任何响应之前基础连接已关闭，则客户端可以建立新连接并重试幂等请求。它知道重复请求将具有相同的预期效果，即使原始请求成功，尽管响应可能不同。
Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see [RFC7234]. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.
请求方法可以定义为“可缓存”，以指示允许存储对它们的响应以供将来重用；具体要求见[RFC7234]。通常，不依赖于当前或权威响应的安全方法被定义为可缓存的；该规范将GET、HEAD和POST定义为可缓存的，尽管绝大多数缓存实现只支持GET和HEAD。
The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
GET方法请求传输目标资源的当前选定表示形式。GET是信息检索的主要机制，也是几乎所有性能优化的焦点。因此，当人们谈到通过HTTP检索一些可识别信息时，他们通常指的是发出GET请求。
It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of such files. In fact, that is how many resources are implemented (see Section 9.1 for related security considerations). However, there are no such limitations in practice. The HTTP interface for a resource is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured to execute the files with the request as input and send the output as the representation rather than transfer the files directly. Regardless, only the origin server needs to know how each of its resource
人们很容易将资源标识符视为远程文件系统路径名，将表示形式视为此类文件内容的副本。事实上，这就是实现了多少资源（有关安全方面的考虑，请参见第9.1节）。然而，在实践中没有这种限制。资源的HTTP接口很可能实现为内容对象树、各种数据库记录的编程视图或其他信息系统的网关。即使URI映射机制绑定到文件系统，源服务器也可能被配置为以请求作为输入执行文件，并将输出作为表示发送，而不是直接传输文件。无论如何，只有源服务器需要知道它的每个资源
identifiers corresponds to an implementation and how each implementation manages to select and send a current representation of the target resource in a response to GET.
标识符对应于一个实现，以及每个实现如何在GET响应中选择并发送目标资源的当前表示形式。
A client can alter the semantics of GET to be a "range request", requesting transfer of only some part(s) of the selected representation, by sending a Range header field in the request ([RFC7233]).
客户机可以通过在请求（[RFC7233]）中发送范围标头字段，将GET的语义更改为“范围请求”，请求仅传输所选表示的某些部分。
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。
The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [RFC7234]).
对GET请求的响应是可缓存的；缓存可以使用它来满足后续的GET和HEAD请求，除非缓存控制头字段（RFC7234的第5.2节）另有指示。
The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation data and is often used for testing hypertext links for validity, accessibility, and recent modification.
HEAD方法与GET方法相同，只是服务器不能在响应中发送消息体（即，响应终止于header部分的末尾）。服务器响应HEAD请求时应发送与请求为GET时相同的报头字段，但可省略有效负载报头字段（第3.3节）。此方法可用于在不传输表示数据的情况下获取所选表示的元数据，并且通常用于测试超文本链接的有效性、可访问性和最近的修改。
A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request.
头部请求消息中的有效负载没有定义的语义；在HEAD请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。
The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD response might also have an effect on previously cached responses to GET; see Section 4.3.5 of [RFC7234].
对头部请求的响应是可缓存的；除非缓存控制头字段（RFC7234第5.2节）另有指示，否则缓存可以使用它来满足后续的头请求。HEAD响应也可能会对以前缓存的响应产生影响，以便获取；见[RFC7234]第4.3.5节。
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
POST方法请求目标资源根据资源自身的特定语义处理请求中包含的表示。例如，POST用于以下功能（除其他功能外）：
o Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
o 向数据处理过程提供数据块，例如输入HTML表单的字段；
o Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
o 向公告栏、新闻组、邮件列表、博客或类似文章组发布消息；
o Creating a new resource that has yet to be identified by the origin server; and
o 创建尚未由源服务器标识的新资源；和
o Appending data to a resource's existing representation(s).
o 将数据附加到资源的现有表示形式。
An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).
源服务器通过根据处理POST请求的结果选择适当的状态代码来指示响应语义；本规范定义的几乎所有状态代码都可以在对POST的响应中接收（例外情况为206（部分内容）、304（未修改）和416（范围不可满足））。
If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).
如果由于成功处理POST请求而在源服务器上创建了一个或多个资源，则源服务器应发送201（已创建）响应，其中包含位置标头字段，该字段为所创建的主资源提供标识符（第7.1.2节）以及描述请求状态的表示，同时引用新资源。
Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).
对POST请求的响应只有在包含明确的新鲜度信息时才可缓存（见[RFC7234]第4.2.1节）。然而，后缓存并没有得到广泛的实现。对于源服务器希望客户端能够以可由以后的GET重用的方式缓存POST结果的情况，源服务器可以发送200（OK）响应，其中包含结果和与POST的有效请求URI具有相同值的内容位置头字段（第3.1.4.2节）。
If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field. This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.
如果处理POST的结果将等同于现有资源的表示，则源服务器可以通过在位置字段中发送具有现有资源的标识符的303（参见其他）响应来将用户代理重定向到该资源。这样做的好处是为用户代理提供一个资源标识符，并通过更适合共享缓存的方法传输表示，尽管如果用户代理尚未缓存表示，则需要额外请求。
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that
PUT方法请求创建目标资源的状态，或将其替换为请求消息负载中包含的表示所定义的状态。对给定表示的成功PUT将表明，对同一目标资源的后续GET将导致在200（OK）响应中发送等效表示。然而，不能保证
such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
这种状态变化是可以观察到的，因为在接收任何后续GET之前，目标资源可能会由其他用户代理并行操作，或者可能会受到源服务器的动态处理。成功的响应仅意味着用户代理的意图是在源服务器处理时实现的。
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.
如果目标资源没有当前表示，并且PUT成功创建了一个表示，则源服务器必须通过发送201（已创建）响应通知用户代理。如果目标资源确实具有当前表示，并且根据所附表示的状态成功修改了该表示，则源服务器必须发送200（确定）或204（无内容）响应以指示请求成功完成。
An origin server SHOULD ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
源服务器应忽略PUT请求中接收到的无法识别的头字段（即，不要将它们保存为资源状态的一部分）。
An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent with the target resource, the origin server SHOULD either make them consistent, by transforming the representation or changing the resource configuration, or respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type values.
源服务器应验证PUT表示是否与服务器对目标资源的任何约束一致，这些约束不能或不会被PUT更改。当源服务器使用与URI相关的内部配置信息来设置GET响应上表示元数据的值时，这一点尤为重要。当PUT表示与目标资源不一致时，源服务器应通过转换表示或更改资源配置使其一致，或使用包含足够信息的适当错误消息进行响应，以解释表示不合适的原因。建议使用409（冲突）或415（不支持的媒体类型）状态代码，后者特定于内容类型值的约束。
For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:
例如，如果将目标资源配置为始终具有“text/html”的内容类型，并且所放置的表示具有“image/jpeg”的内容类型，则源服务器应执行以下操作之一：
a. reconfigure the target resource to reflect the new media type;
a. 重新配置目标资源以反映新媒体类型；
b. transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; or,
b. 将PUT表示转换为与资源一致的格式，然后将其保存为新的资源状态；或
c. reject the request with a 415 (Unsupported Media Type) response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would be a suitable target for the new representation.
c. 用415（不支持的媒体类型）响应拒绝请求，该响应指示目标资源被限制为“文本/html”，可能包括指向将是新表示的合适目标的不同资源的链接。
HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how such storage might change as a result of a change in resource state, nor how the origin server translates resource state into representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server.
除了用户代理请求的意图和源服务器响应的语义所能表达的内容外，HTTP并没有准确定义PUT方法如何影响源服务器的状态。它没有定义在通过HTTP提供的接口之外的任何意义上的资源。它没有定义如何“存储”资源状态，也没有定义由于资源状态的变化而导致的存储变化，也没有定义源服务器如何将资源状态转换为表示。一般来说，服务器有意隐藏资源接口后面的所有实现细节。
An origin server MUST NOT send a validator header field (Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).
原始服务器在成功响应PUT时不得发送验证程序标头字段（第7.2节），如ETag或Last Modified字段，除非请求的表示数据在未对正文应用任何转换的情况下保存（即，资源的新表示数据与PUT请求中接收的表示数据相同）而validator字段值反映了新的表示形式。此要求允许用户代理知道它在内存中的表示形式何时因PUT而保持最新，因此不需要再次从源服务器检索，以及新的验证器在响应中接收的数据可用于未来的有条件请求，以防止意外覆盖（第5.2节）。
The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
POST和PUT方法之间的根本区别在于所附表示的不同意图。POST请求中的目标资源旨在根据资源自身的语义处理封闭表示，而PUT请求中的封闭表示被定义为替换目标资源的状态。因此，PUT的意图是幂等的，并且对中介体可见，即使确切的效果只有源服务器知道。
Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved to a different URI, then the origin server MUST send an appropriate 3xx (Redirection) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
对PUT请求的正确解释假定用户代理知道需要哪个目标资源。在接收到状态更改请求后，代表客户端选择适当URI的服务应该使用POST方法而不是PUT方法来实现。如果源服务器不会对目标资源进行请求的PUT状态更改，而是希望将其应用于不同的资源，例如当资源已移动到不同的URI时，则源服务器必须发送适当的3xx（重定向）响应；然后，用户代理可以自行决定是否重定向请求。
A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources
应用于目标资源的PUT请求可能会对其他资源产生副作用。例如，一篇文章可能有一个用于标识“当前版本”（资源）的URI，该URI与标识每个特定版本（不同资源）的URI是分开的
that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.
在某一点上与当前版本资源共享相同的状态）。因此，对“当前版本”URI的成功PUT请求除了更改目标资源的状态外，还可能创建新的版本资源，并且还可能导致在相关资源之间添加链接。
An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (Section 4.2 of [RFC7233]), since the payload is likely to be partial content that has been mistakenly PUT as a full representation. Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789]).
允许对给定目标资源进行PUT的源服务器必须向包含内容范围标头字段的PUT请求发送400（错误请求）响应（RFC7233的第4.2节），因为有效负载可能是被错误地作为完整表示的部分内容。部分内容更新可以通过以下方式实现：以状态与较大资源的一部分重叠的单独标识的资源为目标，或者使用专门为部分更新定义的不同方法（例如，[RFC5789]中定义的修补方法）。
Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
对PUT方法的响应不可缓存。如果成功的PUT请求通过一个缓存，该缓存具有一个或多个针对有效请求URI的存储响应，则这些存储响应将无效（请参阅[RFC7234]第4.4节）。
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
DELETE方法请求源服务器删除目标资源与其当前功能之间的关联。实际上，此方法类似于UNIX中的rm命令：它表示对源服务器的URI映射的删除操作，而不是期望删除以前关联的信息。
If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion.
如果目标资源具有一个或多个当前表示形式，则源服务器可能会或不会销毁这些表示形式，并且相关存储可能会或不会被回收，这完全取决于资源的性质以及源服务器对其的实现（这超出了本规范的范围）。同样，由于删除，可能需要停用或归档资源的其他实现方面，例如数据库或网关连接。通常，假定源服务器只允许删除其具有完成删除的指定机制的资源。
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified via the Location header field after a 201 (Created) response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent implementations that implement
相对较少的资源允许使用DELETE方法——它的主要用途是用于远程创作环境，用户对其效果有一定的指导。例如，先前使用PUT请求创建的资源，或在对POST请求的201（已创建）响应之后通过Location header字段标识的资源，可能允许相应的删除请求撤消这些操作。类似地，实现
an authoring function, such as revision control clients using HTTP for remote operations, might use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
编写功能（例如使用HTTP进行远程操作的修订控制客户端）可能会基于以下假设使用DELETE：服务器的URI空间已精心编制，以对应于版本存储库。
If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.
如果成功应用删除方法，则源服务器应发送202（已接受）状态代码（如果操作可能成功但尚未实施），204（无内容）状态代码（如果操作已实施且无需提供进一步信息），或200（确定）状态代码，如果操作已实施且响应消息包含描述状态的表示。
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.
删除请求消息中的有效负载没有定义的语义；在删除请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。
Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
对DELETE方法的响应不可缓存。如果删除请求通过具有一个或多个有效请求URI存储响应的缓存，则这些存储响应将无效（请参阅[RFC7234]第4.4节）。
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, [RFC5246]).
CONNECT方法请求接收方建立到由请求目标标识的目标源服务器的隧道，如果成功，则随后将其行为限制为双向盲转发数据包，直到隧道关闭。隧道通常用于通过一个或多个代理创建端到端虚拟连接，然后可以使用TLS（传输层安全[RFC5246]）对其进行保护。
CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself MAY respond with a 2xx (Successful) status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
CONNECT仅用于对代理的请求。接收自身连接请求的源服务器可能会响应2xx（成功）状态代码，以指示已建立连接。但是，大多数源服务器不实现连接。
A client sending a CONNECT request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. For example,
发送连接请求的客户端必须发送请求目标的授权表（RFC7230第5.3节）；i、 例如，请求目标仅由隧道目标的主机名和端口号组成，用冒号分隔。例如
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another proxy, by forwarding the CONNECT request to the next inbound proxy. Any 2xx (Successful) response indicates that the sender (and all
收件人代理可以通过直接连接到请求目标或（如果配置为使用另一个代理）将连接请求转发到下一个入站代理来建立隧道。任何2xx（成功）响应都表示发送方（以及所有
inbound proxies) will switch to tunnel mode immediately after the blank line that concludes the successful response's header section; data received after that blank line is from the server identified by the request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains governed by HTTP.
入站代理将在结束成功响应的标题部分的空白行之后立即切换到隧道模式；在该空行之后接收的数据来自由请求目标标识的服务器。除了成功响应之外的任何响应都表明隧道尚未形成，并且连接仍然由HTTP控制。
A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary MUST attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard any remaining data left undelivered.
当隧道中介检测到任何一方已关闭其连接时，隧道将关闭：中介必须尝试将来自关闭方的任何未完成数据发送到另一方，关闭两个连接，然后丢弃任何未交付的剩余数据。
Proxy authentication might be used to establish the authority to create a tunnel. For example,
代理身份验证可用于建立创建隧道的权限。例如
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.
建立到任意服务器的隧道有很大的风险，特别是当目标是一个众所周知的或保留的TCP端口，而该端口不用于Web流量时。例如，连接到请求目标“example.com:25”将建议代理连接到SMTP通信的保留端口；如果允许，这可能会欺骗代理转发垃圾邮件。支持CONNECT的代理应将其使用限制为有限的已知端口集或可配置的安全请求目标白名单。
A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
服务器不得在2xx（成功）响应中发送任何传输编码或内容长度头字段以连接。客户端必须忽略在成功响应中接收到的任何内容长度或传输编码头字段才能连接。
A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.
连接请求消息中的有效负载没有定义的语义；在连接请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。
Responses to the CONNECT method are not cacheable.
对CONNECT方法的响应不可缓存。
The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.
OPTIONS方法请求有关目标资源可用的通信选项的信息，这些通信选项位于源服务器或中介。此方法允许客户机确定与资源或服务器功能相关的选项和/或需求，而无需执行资源操作。
An OPTIONS request with an asterisk ("*") as the request-target (Section 5.3 of [RFC7230]) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
以星号（“*”）作为请求目标的选项请求（RFC7230]第5.3节）一般适用于服务器，而不是特定资源。由于服务器的通信选项通常取决于资源，“*”请求仅作为“ping”或“no op”类型的方法有用；它只允许客户端测试服务器的功能。例如，这可用于测试代理是否符合HTTP/1.1（或是否不符合）。
If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.
如果请求目标不是星号，则选项请求将应用于与目标资源通信时可用的选项。
A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.
生成对选项的成功响应的服务器应发送任何头字段，这些头字段可能指示由服务器实现并适用于目标资源的可选功能（例如，允许），包括本规范未定义的潜在扩展。响应有效负载（如果有的话）还可以在机器或人类可读表示中描述通信选项。这种表示的标准格式不在本规范中定义，但可能在将来的HTTP扩展中定义。如果响应中不发送有效负载正文，则服务器必须生成值为“0”的内容长度字段。
A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 5.1.2). A proxy MUST NOT generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
客户机可在选项请求中向请求链中的特定收件人发送Max Forwards标头字段（参见第5.1.2节）。代理在转发请求时不得生成Max Forwards标头字段，除非该请求是通过Max Forwards字段接收的。
A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
生成包含有效负载正文的选项请求的客户端必须发送描述表示媒体类型的有效内容类型标头字段。尽管此规范没有定义此类有效负载的任何用途，但HTTP的未来扩展可能会使用选项体对目标资源进行更详细的查询。
Responses to the OPTIONS method are not cacheable.
对OPTIONS方法的响应不可缓存。
The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the message body of a 200 (OK) response with a Content-Type of "message/http" (Section 8.3.1 of [RFC7230]). The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request (Section 5.1.2).
TRACE方法请求请求消息的远程应用程序级循环。请求的最终接收者应将收到的消息（不包括下文所述的某些字段）作为内容类型为“消息/http”的200（确定）响应的消息正文（RFC7230的第8.3.1节）反映回客户端。最后一个收件人是原始服务器或第一个在请求中接收最大转发值为零（0）的服务器（第5.1.2节）。
A client MUST NOT generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The final recipient of the request SHOULD exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
客户端不得在跟踪请求中生成包含响应可能披露的敏感数据的头字段。例如，用户代理在跟踪请求中发送存储的用户凭据[RFC7235]或Cookie[RFC6265]是愚蠢的。请求的最终接收者应排除在该接收者生成响应正文时可能包含敏感数据的任何请求头字段。
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (Section 5.7.1 of [RFC7230]) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
跟踪允许客户端查看在请求链的另一端接收到的内容，并将该数据用于测试或诊断信息。Via头字段（RFC7230的第5.7.1节）的值特别重要，因为它充当请求链的跟踪。使用Max Forwards标头字段允许客户端限制请求链的长度，这对于测试无限循环中转发消息的代理链非常有用。
A client MUST NOT send a message body in a TRACE request.
客户端不得在跟踪请求中发送消息正文。
Responses to the TRACE method are not cacheable.
对跟踪方法的响应不可缓存。
A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing. These fields act as request modifiers, similar to the parameters on a programming language method invocation.
客户端发送请求头字段以提供有关请求上下文的更多信息，根据目标资源状态使请求有条件，建议响应的首选格式，提供身份验证凭据，或修改预期的请求处理。这些字段充当请求修饰符，类似于编程语言方法调用上的参数。
Controls are request header fields that direct specific handling of the request.
控件是请求头字段，用于指导请求的特定处理。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Cache-Control | Section 5.2 of [RFC7234] |
| Expect | Section 5.1.1 |
| Host | Section 5.4 of [RFC7230] |
| Max-Forwards | Section 5.1.2 |
| Pragma | Section 5.4 of [RFC7234] |
| Range | Section 3.1 of [RFC7233] |
| TE | Section 4.3 of [RFC7230] |
+-------------------+--------------------------+
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Cache-Control | Section 5.2 of [RFC7234] |
| Expect | Section 5.1.1 |
| Host | Section 5.4 of [RFC7230] |
| Max-Forwards | Section 5.1.2 |
| Pragma | Section 5.4 of [RFC7234] |
| Range | Section 3.1 of [RFC7233] |
| TE | Section 4.3 of [RFC7230] |
+-------------------+--------------------------+
The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request. The only such expectation defined by this specification is 100-continue.
请求中的“Expect”头字段表示服务器需要支持的一组行为（期望），以便正确处理此请求。本规范中定义的唯一此类期望是100 continue。
Expect = "100-continue"
Expect = "100-continue"
The Expect field-value is case-insensitive.
Expect字段值不区分大小写。
A server that receives an Expect field-value other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.
接收到除100 continue以外的Expect字段值的服务器可能会响应417（Expectation Failed）状态代码，以指示无法满足意外的期望。
A 100-continue expectation informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a 100 (Continue) interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error response. This allows the client to wait for an indication that it is worthwhile to send the message body before actually doing so, which can improve efficiency when the message body is huge or when the client anticipates that an error is likely (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).
如果请求行和标头字段不足以导致立即成功、重定向或错误响应，则100 continue预期将通知收件人客户端将在此请求中发送（可能较大）消息正文，并希望接收100（continue）临时响应。这允许客户机在实际发送消息体之前等待消息体值得发送的指示，这可以在消息体很大或客户机预计可能发生错误时提高效率（例如，首次发送状态更改方法时，没有事先验证的身份验证凭据）。
For example, a request that begins with
例如，以开头的请求
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
allows the origin server to immediately respond with an error message, such as 401 (Unauthorized) or 405 (Method Not Allowed), before the client starts filling the pipes with an unnecessary data transfer.
允许源服务器在客户端开始用不必要的数据传输填充管道之前立即响应错误消息，例如401（未经授权）或405（不允许使用方法）。
Requirements for clients:
对客户的要求：
o A client MUST NOT generate a 100-continue expectation in a request that does not include a message body.
o 客户端不得在不包含消息正文的请求中生成100 continue预期。
o A client that will wait for a 100 (Continue) response before sending the request message body MUST send an Expect header field containing a 100-continue expectation.
o 在发送请求消息正文之前等待100（Continue）响应的客户端必须发送包含100 Continue预期的Expect标头字段。
o A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the message body even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the message body.
o 发送100个连续期望值的客户端不需要等待任何特定的时间长度；这样的客户端即使尚未收到响应，也可以继续发送消息体。此外，由于无法通过HTTP/1.0中介发送100（Continue）响应，因此这样的客户机在发送消息体之前不应无限期等待。
o A client that receives a 417 (Expectation Failed) status code in response to a request containing a 100-continue expectation SHOULD repeat that request without a 100-continue expectation, since the 417 response merely indicates that the response chain does not support expectations (e.g., it passes through an HTTP/1.0 server).
o 接收到417（期望失败）状态代码以响应包含100个持续期望的请求的客户端应重复该请求而不包含100个持续期望，因为417响应仅指示响应链不支持期望（例如，它通过HTTP/1.0服务器）。
Requirements for servers:
对服务器的要求：
o A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
o 在HTTP/1.0请求中收到100 continue期望值的服务器必须忽略该期望值。
o A server MAY omit sending a 100 (Continue) response if it has already received some or all of the message body for the corresponding request, or if the framing indicates that there is no message body.
o 如果服务器已经接收到相应请求的部分或全部消息体，或者如果帧表示没有消息体，则服务器可以忽略发送100（Continue）响应。
o A server that sends a 100 (Continue) response MUST ultimately send a final status code, once the message body is received and processed, unless the connection is closed prematurely.
o 发送100（Continue）响应的服务器必须在接收和处理消息正文后最终发送最终状态代码，除非连接过早关闭。
o A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 6.6 of [RFC7230]).
o 在读取整个消息正文之前，以最终状态代码进行响应的服务器应在该响应中指示其是否打算关闭连接或继续读取和丢弃请求消息（请参阅[RFC7230]第6.6节）。
An origin server MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or send an immediate 100 (Continue) response to encourage the client to send the request's message body. The origin server MUST NOT wait for the message body before sending the 100 (Continue) response.
原始服务器在收到HTTP/1.1（或更高版本）请求行和包含100 continue预期并指示请求消息正文将遵循的完整标头部分后，必须立即发送带有最终状态代码的响应（如果仅通过检查请求行和标头字段即可确定该状态），或者立即发送100（Continue）响应以鼓励客户端发送请求的消息体。在发送100（继续）响应之前，源服务器不得等待消息正文。
A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or begin forwarding the request toward the origin server by sending a
代理必须在收到HTTP/1.1（或更高版本）请求行和包含100 continue预期并指示请求消息正文将跟随的完整标头部分后，立即发送带有最终状态代码的响应（如果仅通过检查请求行和标头字段即可确定该状态），或者通过发送
corresponding request-line and header section to the next inbound server. If the proxy believes (from configuration or past interaction) that the next inbound server only supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response to encourage the client to begin sending the message body.
对应于下一个入站服务器的请求行和标头部分。如果代理相信（从配置或过去的交互）下一个入站服务器只支持HTTP/1.0，则代理可能会生成立即100（继续）响应，以鼓励客户端开始发送消息体。
Note: The Expect header field was added after the original publication of HTTP/1.1 [RFC2068] as both the means to request an interim 100 (Continue) response and the general mechanism for indicating must-understand extensions. However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented by many servers, rendering the extension mechanism useless. This specification has removed the extension mechanism in order to simplify the definition and processing of 100-continue.
注意：Expect header字段是在最初发布HTTP/1.1[RFC2068]之后添加的，它既是请求临时100（Continue）响应的手段，也是指示必须理解的扩展的一般机制。然而，扩展机制还没有被客户端使用，而且必须理解的需求也没有被许多服务器实现，这使得扩展机制毫无用处。本规范删除了扩展机制，以简化100 continue的定义和处理。
The "Max-Forwards" header field provides a mechanism with the TRACE (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting to trace a request that appears to be failing or looping mid-chain.
“Max Forwards”（最大转发）标头字段提供了一种带有跟踪（第4.3.8节）和选项（第4.3.7节）请求方法的机制，以限制代理转发请求的次数。当客户端试图跟踪一个似乎失败或循环中链的请求时，这可能很有用。
Max-Forwards = 1*DIGIT
Max-Forwards = 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.
Max Forwards值是一个十进制整数，指示此请求消息可以转发的剩余次数。
Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary MUST NOT forward the request; instead, the intermediary MUST respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary MUST generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of a) the received value decremented by one (1) or b) the recipient's maximum supported value for Max-Forwards.
接收到包含Max Forwards标头字段的跟踪或选项请求的每个中介体必须在转发请求之前检查并更新其值。如果收到的值为零（0），则中间人不得转发请求；相反，中间人必须作为最终接受者作出回应。如果接收到的最大转发值大于零，则中间层必须在转发消息中生成一个更新的最大转发字段，该字段的值应为a）接收值减去一（1）或b）收件人支持的最大转发值中的较小值。
A recipient MAY ignore a Max-Forwards header field received with any other request methods.
收件人可以忽略使用任何其他请求方法接收的最大转发头字段。
The HTTP conditional request header fields [RFC7232] allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false. Each precondition defined by
HTTP条件请求头字段[RFC7232]允许客户端在目标资源的状态上放置一个先决条件，这样，如果先决条件的计算结果为false，则不会应用与方法语义相对应的操作。定义的每个先决条件
this specification consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (Section 7.2). Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client. The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in Section 5 of [RFC7232].
本规范包括从目标资源的先前表示中获得的一组验证器与所选表示的验证器的当前状态之间的比较（第7.2节）。因此，这些先决条件评估目标资源的状态是否在客户端已知的给定状态之后发生了更改。如[RFC7232]第5节所定义，此类评估的效果取决于方法语义和条件选择。
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| If-Match | Section 3.1 of [RFC7232] |
| If-None-Match | Section 3.2 of [RFC7232] |
| If-Modified-Since | Section 3.3 of [RFC7232] |
| If-Unmodified-Since | Section 3.4 of [RFC7232] |
| If-Range | Section 3.2 of [RFC7233] |
+---------------------+--------------------------+
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| If-Match | Section 3.1 of [RFC7232] |
| If-None-Match | Section 3.2 of [RFC7232] |
| If-Modified-Since | Section 3.3 of [RFC7232] |
| If-Unmodified-Since | Section 3.4 of [RFC7232] |
| If-Range | Section 3.2 of [RFC7233] |
+---------------------+--------------------------+
The following request header fields are sent by a user agent to engage in proactive negotiation of the response content, as defined in Section 3.4.1. The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol.
如第3.4.1节所定义，以下请求头字段由用户代理发送，以参与响应内容的主动协商。这些字段中发送的首选项适用于响应中的任何内容，包括目标资源的表示、错误或处理状态的表示，甚至可能包括协议中可能出现的杂项文本字符串。
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| Accept | Section 5.3.2 |
| Accept-Charset | Section 5.3.3 |
| Accept-Encoding | Section 5.3.4 |
| Accept-Language | Section 5.3.5 |
+-------------------+---------------+
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| Accept | Section 5.3.2 |
| Accept-Charset | Section 5.3.3 |
| Accept-Encoding | Section 5.3.4 |
| Accept-Language | Section 5.3.5 |
+-------------------+---------------+
Many of the request header fields for proactive negotiation use a common parameter, named "q" (case-insensitive), to assign a relative "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource.
主动协商的许多请求头字段使用一个名为“q”（不区分大小写）的公共参数，为相关内容类型的首选项分配相对“权重”。此权重称为“质量值”（或“qvalue”），因为在服务器配置中经常使用相同的参数名称来为可为资源选择的各种表示的相对质量分配权重。
The weight is normalized to 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". If no "q" parameter is present, the default weight is 1.
将权重标准化为0到1范围内的实数，其中0.001是最不优选的，1是最优选的；值为0表示“不可接受”。如果不存在“q”参数，则默认权重为1。
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the decimal point. User configuration of these values ought to be limited in the same fashion.
qvalue的发送方在小数点后生成的数字不得超过三位。这些值的用户配置应该以同样的方式进行限制。
The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
“Accept”标头字段可由用户代理用于指定可接受的响应媒体类型。Accept头字段可用于指示请求被特别限制为一小部分所需类型，如在线图像请求。
Accept = #( media-range [ accept-params ] )
Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range can include media type parameters that are applicable to that range.
星号“*”字符用于将媒体类型分为不同的范围，“*/*”表示所有媒体类型，“type/*”表示该类型的所有子类型。介质范围可以包括适用于该范围的介质类型参数。
Each media-range might be followed by zero or more applicable media type parameters (e.g., charset), an optional "q" parameter for indicating a relative weight (Section 5.3.1), and then zero or more extension parameters. The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets.
每个介质范围后面可能有零个或多个适用的介质类型参数（例如字符集），一个用于指示相对重量的可选“q”参数（第5.3.1节），然后是零个或多个扩展参数。如果存在任何扩展名（accept ext），则“q”参数是必需的，因为它充当两个参数集之间的分隔符。
Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA
注意：使用“q”参数名称将介质类型参数与接受扩展参数分开是由于历史惯例。尽管这会阻止任何名为“q”的媒体类型参数与媒体范围一起使用，但鉴于IANA中缺少任何“q”参数，这样的事件被认为不太可能发生
media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".
介质类型注册表以及在Accept中很少使用任何介质类型参数。不鼓励将来的媒体类型注册任何名为“q”的参数。
The example
榜样
Accept: audio/*; q=0.2, audio/basic
Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality".
解释为“我更喜欢音频/基本，但如果在质量降低80%后是最好的，请发送任何音频类型给我”。
A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
没有任何Accept标头字段的请求意味着用户代理将接受任何媒体类型作为响应。如果请求中存在标头字段，并且响应的可用表示形式中没有一种媒体类型被列为可接受，则源服务器可以通过发送406（不可接受）响应来尊重标头字段，或者通过将响应视为未经内容协商来忽略标头字段。
A more elaborate example is
一个更详细的例子是
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are the equally preferred media types, but if they do not exist, then send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
口头上，这将被解释为“text/html和text/x-c是同样首选的媒体类型，但如果它们不存在，则发送text/x-dvi表示，如果不存在，则发送text/plain表示”。
Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,
介质范围可以被更具体的介质范围或介质类型覆盖。如果给定类型适用多个媒体范围，则最特定的引用优先。例如
Accept: text/*, text/plain, text/plain;format=flowed, */*
Accept: text/*, text/plain, text/plain;format=flowed, */*
have the following precedence:
具有以下优先权：
1. text/plain;format=flowed
1. 文本/纯文本；格式=流动
2. text/plain
2. 文本/纯文本
3. text/*
3. 正文/*
4. */*
4. */*
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence that matches the type. For example,
与给定类型关联的媒体类型质量因子是通过查找与该类型匹配的具有最高优先级的媒体范围来确定的。例如
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
将导致以下值关联：
+-------------------+---------------+
| Media Type | Quality Value |
+-------------------+---------------+
| text/html;level=1 | 1 |
| text/html | 0.7 |
| text/plain | 0.3 |
| image/jpeg | 0.5 |
| text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 |
+-------------------+---------------+
+-------------------+---------------+
| Media Type | Quality Value |
+-------------------+---------------+
| text/html;level=1 | 1 |
| text/html | 0.7 |
| text/plain | 0.3 |
| image/jpeg | 0.5 |
| text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 |
+-------------------+---------------+
Note: A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user.
注意：用户代理可能会为某些媒体范围提供一组默认的质量值。但是，除非用户代理是无法与其他渲染代理交互的封闭系统，否则此默认设置应由用户配置。
The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.
“Accept Charset”标头字段可以由用户代理发送，以指示文本响应内容中可接受的字符集。该字段允许能够理解更全面或专用字符集的用户代理向能够表示这些字符集中信息的源服务器发送该功能的信号。
Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 3.1.1.2. A user agent MAY associate a quality value with each charset to indicate the user's relative preference for that charset, as defined in Section 5.3.1. An example is
第3.1.1.2节定义了字符集名称。用户代理可以将质量值与每个字符集相关联，以表明用户对该字符集的相对偏好，如第5.3.1节所定义。例如
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field are considered "not acceptable" to the client.
特殊值“*”如果存在于Accept字符集字段中，则与Accept字符集字段中其他地方未提及的每个字符集相匹配。如果Accept字符集字段中不存在“*”，则该字段中未明确提及的任何字符集将被视为客户端“不可接受”。
A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose user agents do not send Accept-Charset, unless specifically
没有任何Accept Charset标头字段的请求意味着用户代理将接受响应中的任何字符集。大多数通用用户代理不发送接受字符集，除非特别说明
configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (Section 9.7).
配置为这样做，因为支持的字符集的详细列表使服务器更容易根据用户代理的请求特征识别个人（第9.7节）。
If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a 406 (Not Acceptable) response, or disregard the header field by treating the resource as if it is not subject to content negotiation.
如果请求中存在Accept Charset标头字段，并且响应的任何可用表示形式都没有列出为可接受的字符集，则源服务器可以通过发送406（不可接受）响应来尊重标头字段，或者忽略标题字段，将资源视为不受内容协商的约束。
The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (Section 3.1.2.1) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.
用户代理可以使用“Accept Encoding”标题字段来指示响应中可接受的响应内容编码（第3.1.2.1节）。“身份”标记用作“无编码”的同义词，以便在首选无编码时进行通信。
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
如第5.3.1节所定义，每个编码值可给出一个表示该编码偏好的相关质量值。接受编码字段中的星号“*”符号与头字段中未明确列出的任何可用内容编码匹配。
For example,
例如
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings. Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings.
没有Accept Encoding标头字段的请求意味着用户代理没有关于内容编码的首选项。尽管这允许服务器在响应中使用任何内容编码，但并不意味着用户代理将能够正确处理所有编码。
A server tests whether a content-coding for a given representation is acceptable using these rules:
服务器使用以下规则测试给定表示的内容编码是否可接受：
1. If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent.
1. 如果请求中没有接受编码字段，则用户代理将认为任何内容编码都是可接受的。
2. If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".
2. 如果表示没有内容编码，则默认情况下可以接受，除非在没有更具体的“标识”条目的情况下，接受编码字段特别排除了“标识；q=0”或“*；q=0”。
3. If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
3. 如果表示的内容编码是Accept Encoding（接受编码）字段中列出的内容编码之一，则表示的内容编码是可接受的，除非它附带Q值0。（如第5.3.1节所定义，Q值为0表示“不可接受”。）
4. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
4. 如果可接受多个内容编码，则首选具有最高非零Q值的可接受内容编码。
An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response. If an Accept-Encoding header field is present in a request and none of the available representations for the response have a content-coding that is listed as acceptable, the origin server SHOULD send a response without any content-coding.
组合字段值为空的Accept Encoding标头字段表示用户代理不希望任何内容编码作为响应。如果请求中存在Accept Encoding标头字段，并且响应的任何可用表示都没有列出为可接受的内容编码，则源服务器应发送不带任何内容编码的响应。
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues might not work and are not permitted with x-gzip or x-compress.
注意：大多数HTTP/1.0应用程序不识别或不遵守与内容编码相关的QValue。这意味着QValue可能不起作用，并且不允许使用x-gzip或x-compress。
The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 3.1.3.1.
用户代理可以使用“Accept Language”标题字段来指示响应中首选的自然语言集。第3.1.3.1节定义了语言标记。
Accept-Language = 1#( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
Accept-Language = 1#( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages specified by that range, as defined in Section 5.3.1. For example,
如第5.3.1节所定义，每个语言范围都可以给出一个相关的质量值，表示用户对该范围指定语言偏好的估计值。例如
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English".
意思是：“我更喜欢丹麦语，但会接受英式英语和其他类型的英语。”。
A request without any Accept-Language header field implies that the user agent will accept any language in response. If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it
没有任何Accept Language标头字段的请求意味着用户代理将接受任何语言作为响应。如果请求中存在标头字段，并且响应的可用表示形式中没有匹配的语言标记，则源服务器可以忽略标头字段，将响应视为
is not subject to content negotiation or honor the header field by sending a 406 (Not Acceptable) response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example).
不受内容协商的约束，或通过发送406（不可接受）响应来尊重标题字段。但是，不鼓励后者，因为这样做会阻止用户访问他们可能会使用的内容（例如，使用翻译软件）。
Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality. Additional discussion of language priority lists can be found in Section 2.3 of [RFC4647].
请注意，有些收件人将语言标记的列出顺序视为优先级递减的指示，特别是对于被分配了同等质量值（没有值与q=1相同）的标记。然而，这种行为是不可靠的。为了一致性和最大化互操作性，许多用户代理为每个语言标记分配一个唯一的质量值，同时也按质量降低的顺序列出它们。关于语言优先级列表的更多讨论，请参见[RFC4647]第2.3节。
For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined for HTTP in Section 14.4 of [RFC2616].
对于匹配，[RFC4647]的第3节定义了几种匹配方案。实现可以为其需求提供最合适的匹配方案。“基本过滤”方案（[RFC4647]，第3.3.1节）与之前在[RFC2616]第14.4节中为HTTP定义的匹配方案相同。
It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic preferences of the user in every request (Section 9.7).
在每个请求中发送包含用户完整语言偏好的Accept Language header字段（第9.7节），可能与用户的隐私期望相反。
Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic preference (either through configuration of the user agent itself or by defaulting to a user controllable system setting). A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field.
由于可理解性高度依赖于单个用户，用户代理需要允许用户控制语言偏好（通过配置用户代理本身或默认为用户可控制的系统设置）。未向用户提供此类控制的用户代理不得发送Accept Language标头字段。
Note: User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest, in such a case, to add "en" to the list for better matching behavior.
注意：用户代理应该在设置偏好时为用户提供指导，因为用户很少熟悉上述语言匹配的细节。例如，用户可能会假设在选择“en gb”时，如果没有英式英语，他们将收到任何类型的英语文档。在这种情况下，用户代理可能会建议将“en”添加到列表中，以实现更好的匹配行为。
Two header fields are used for carrying authentication credentials, as defined in [RFC7235]. Note that various custom mechanisms for user authentication use the Cookie header field for this purpose, as defined in [RFC6265].
两个标头字段用于承载身份验证凭据，如[RFC7235]中所定义。请注意，用于用户身份验证的各种自定义机制为此目的使用Cookie头字段，如[RFC6265]中所定义。
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| Authorization | Section 4.2 of [RFC7235] |
| Proxy-Authorization | Section 4.4 of [RFC7235] |
+---------------------+--------------------------+
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| Authorization | Section 4.2 of [RFC7235] |
| Proxy-Authorization | Section 4.4 of [RFC7235] |
+---------------------+--------------------------+
The following request header fields provide additional information about the request context, including information about the user, user agent, and resource behind the request.
以下请求头字段提供了有关请求上下文的附加信息，包括有关用户、用户代理和请求背后的资源的信息。
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| From | Section 5.5.1 |
| Referer | Section 5.5.2 |
| User-Agent | Section 5.5.3 |
+-------------------+---------------+
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| From | Section 5.5.1 |
| Referer | Section 5.5.2 |
| User-Agent | Section 5.5.3 |
+-------------------+---------------+
The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:
“发件人”标题字段包含控制请求用户代理的人工用户的Internet电子邮件地址。地址应该是机器可用的，如[RFC5322]第3.4节中“邮箱”所定义：
From = mailbox
From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4>
mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is:
例如：
From: webmaster@example.org
发件人：webmaster@example.org
The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy.
“发件人标头”字段很少由非机器人用户代理发送。用户代理不应在未经用户明确配置的情况下发送From标头字段，因为这可能会与用户的隐私利益或其站点的安全策略相冲突。
A robotic user agent SHOULD send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests.
robot用户代理应发送有效的From标头字段，以便在服务器出现问题时（例如，robot发送的请求过多、不需要或无效）可以联系负责运行robot的人员。
A server SHOULD NOT use the From header field for access control or authentication, since most recipients will assume that the field value is public information.
服务器不应使用From header字段进行访问控制或身份验证，因为大多数收件人都会假定字段值是公共信息。
The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled). A user agent MUST NOT include the fragment and userinfo components of the URI reference [RFC3986], if any, when generating the Referer field value.
“Referer”[sic]头字段允许用户代理为获取目标URI的资源指定URI引用（即“Referer”，尽管字段名拼写错误）。在生成Referer字段值时，用户代理不得包含URI引用[RFC3986]的片段和userinfo组件（如果有）。
Referer = absolute-URI / partial-URI
Referer = absolute-URI / partial-URI
The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It also allows obsolete or mistyped links to be found for maintenance. Some servers use the Referer header field as a means of denying links from other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain it.
Referer header字段允许服务器生成指向其他资源的反向链接，以进行简单分析、日志记录、优化缓存等。它还允许查找过时或键入错误的链接进行维护。一些服务器使用Referer头字段作为拒绝来自其他站点的链接（所谓的“深度链接”）或限制跨站点请求伪造（CSRF）的手段，但并非所有请求都包含该字段。
Example:
例子：
Referer: http://www.example.org/hypertext/Overview.html
Referer: http://www.example.org/hypertext/Overview.html
If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry within the user's bookmarks/favorites), the user agent MUST either exclude the Referer field or send it with a value of "about:blank".
如果目标URI是从没有自己URI的源（例如，从用户键盘输入，或用户书签/收藏夹中的条目）获取的，则用户代理必须排除Referer字段或使用“about:blank”值发送该字段。
The Referer field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol. See Section 9.4 for additional security considerations.
Referer字段可能会泄露有关用户的请求上下文或浏览历史的信息，如果引用资源的标识符泄露了个人信息（如帐户名）或本应保密的资源（如防火墙后或安全服务内部），则这是一个隐私问题. 当引用资源是本地“文件”或“数据”URI时，大多数通用用户代理不发送Referer头字段。如果引用页面是通过安全协议接收的，则用户代理不得在不安全的HTTP请求中发送引用者标头字段。更多安全注意事项见第9.4节。
Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the request target.
已知一些中介会从传出请求中不加区别地删除Referer头字段。这有一个不幸的副作用，即干扰了针对CSRF攻击的保护，而CSRF攻击对用户的危害可能要大得多。希望限制Referer中信息披露的中介机构和用户代理扩展应将其更改限制为特定编辑，例如用假名替换内部域名或截断查询和/或路径组件。当字段值与请求目标共享相同的方案和主机时，中介不应修改或删除Referer header字段。
The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. A user agent SHOULD send a User-Agent field in each request unless specifically configured not to do so.
“用户代理”标题字段包含有关发起请求的用户代理的信息，服务器通常使用该信息来帮助确定报告的互操作性问题的范围，解决或调整响应以避免特定的用户代理限制，以及进行有关浏览器或操作系统使用的分析。用户代理应在每个请求中发送用户代理字段，除非专门配置为不发送。
User-Agent = product *( RWS ( product / comment ) )
User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), which together identify the user agent software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists of a name and optional version.
用户代理字段值由一个或多个产品标识符组成，每个标识符后面都有零个或多个注释（RFC7230第3.2节），这些注释共同标识用户代理软件及其重要子产品。按照惯例，产品标识符按其重要性的降序排列，用于识别用户代理软件。每个产品标识符由名称和可选版本组成。
product = token ["/" product-version] product-version = token
产品=令牌[“/”产品版本]产品版本=令牌
A sender SHOULD limit generated product identifiers to what is necessary to identify the product; a sender MUST NOT generate advertising or other nonessential information within the product identifier. A sender SHOULD NOT generate information in product-version that is not a version identifier (i.e., successive versions of the same product name ought to differ only in the product-version portion of the product identifier).
发送方应将生成的产品标识符限制在识别产品所需的范围内；发送者不得在产品标识中生成广告或其他非必要信息。发送方不应在不是版本标识符的产品版本中生成信息（即，相同产品名称的后续版本应仅在产品标识符的产品版本部分不同）。
Example:
例子：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting").
用户代理不应生成包含不必要的细粒度细节的用户代理字段，并应限制第三方添加子产品。过长且详细的用户代理字段值会增加请求延迟和违背用户意愿识别用户的风险（“指纹识别”）。
Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.
类似地，鼓励实现不要使用其他实现的产品令牌来声明与它们的兼容性，因为这会绕过该字段的用途。如果用户代理伪装成不同的用户代理，则接收者可以假设用户有意希望看到为该已识别的用户代理定制的响应，即使这些响应可能对正在使用的实际用户代理不起作用。
The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
status code元素是一个三位整数代码，表示试图理解和满足请求的结果。
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
HTTP状态代码是可扩展的。HTTP客户端不需要理解所有注册状态代码的含义，尽管这种理解显然是可取的。但是，客户机必须了解任何状态代码的类别（如第一位数字所示），并将未识别的状态代码视为等同于该类别的x00状态代码，但收件人不得缓存具有未识别状态代码的响应。
For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
例如，如果客户端接收到无法识别的状态代码471，则客户端可以假定其请求有问题，并将响应视为收到400（错误请求）状态代码。响应消息通常包含解释状态的表示。
The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit:
状态代码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。第一个数字有五个值：
o 1xx (Informational): The request was received, continuing process
o 1xx（信息性）：已收到请求，正在继续处理
o 2xx (Successful): The request was successfully received, understood, and accepted
o 2xx（成功）：请求已成功接收、理解和接受
o 3xx (Redirection): Further action needs to be taken in order to complete the request
o 3xx（重定向）：需要采取进一步的操作以完成请求
o 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
o 4xx（客户端错误）：请求包含错误语法或无法实现
o 5xx (Server Error): The server failed to fulfill an apparently valid request
o 5xx（服务器错误）：服务器未能完成明显有效的请求
The status codes listed below are defined in this specification, Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of [RFC7235]. The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol.
下列状态代码在本规范、[RFC7232]第4节、[RFC7233]第4节和[RFC7235]第3节中定义。这里列出的原因短语只是建议——它们可以被本地等价物替换，而不会影响协议。
Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [RFC7234]; all other status codes are not cacheable by default.
除非方法定义或显式缓存控制[RFC7234]另有指示，否则具有默认定义为可缓存状态代码的响应（例如，本规范中的200、203、204、206、300、301、404、405、410、414和501）可由具有启发式过期的缓存重用；默认情况下，所有其他状态代码都不可缓存。
+------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+
+------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+
Note that this list is not exhaustive -- it does not include extension status codes defined in other specifications. The complete list of status codes is maintained by IANA. See Section 8.2 for details.
请注意，此列表并非详尽无遗——它不包括其他规范中定义的扩展状态代码。IANA维护状态代码的完整列表。详见第8.2节。
The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. 1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section). Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.
1xx（信息）类状态代码表示在完成请求的操作并发送最终响应之前，用于传达连接状态或请求进度的临时响应。1xx响应由状态行之后的第一个空行终止（空行表示报头部分结束）。由于HTTP/1.0未定义任何1xx状态代码，因此服务器不得向HTTP/1.0客户端发送1xx响应。
A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.
客户机必须能够解析在最终响应之前收到的一个或多个1xx响应，即使客户机不希望这样。用户代理可能会忽略意外的1xx响应。
A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).
除非代理本身请求生成1xx响应，否则代理必须转发1xx响应。例如，如果代理在转发请求时添加了“Expect:100 continue”字段，则不需要转发相应的100（continue）响应。
The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.
100（Continue）状态代码表示请求的初始部分已被接收，并且尚未被服务器拒绝。服务器打算在请求被完全接收并执行之后发送最终响应。
When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in Section 5.1.1. The client ought to continue sending the request and discard the 100 response.
如第5.1.1节所述，当请求包含包含100 continue期望的Expect标头字段时，100响应表示服务器希望接收请求有效负载正文。客户端应该继续发送请求并放弃100响应。
If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.
如果请求不包含包含100 continue预期的Expect标头字段，则客户端可以简单地放弃此临时响应。
The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field (Section 6.7 of [RFC7230]), for a change in the application protocol being used on this connection. The server
101（交换协议）状态代码表示服务器理解并愿意通过Upgrade header字段（RFC7230的第6.7节）遵守客户端的请求，以更改此连接上使用的应用协议。服务器
MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.
必须在响应中生成一个Upgrade header字段，该字段指示在终止101响应的空行之后立即切换到哪个协议。
It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
假定服务器仅在有利的情况下才同意切换协议。例如，切换到较新版本的HTTP可能比较旧版本更为有利，而在交付使用此类功能的资源时，切换到实时同步协议可能更为有利。
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
2xx（成功）类状态代码表示客户的请求已成功接收、理解和接受。
The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
200（正常）状态代码表示请求已成功。在200响应中发送的有效负载取决于请求方法。对于本规范定义的方法，有效载荷的预期含义可概括为：
GET a representation of the target resource;
获取目标资源的表示形式；
HEAD the same representation as GET, but without the representation data;
HEAD与GET具有相同的表示形式，但没有表示形式数据；
POST a representation of the status of, or results obtained from, the action;
张贴行动状态或结果的陈述；
PUT, DELETE a representation of the status of the action;
放置、删除操作状态的表示；
OPTIONS a representation of the communications options;
选项通信选项的表示；
TRACE a representation of the request message as received by the end server.
跟踪终端服务器接收到的请求消息的表示形式。
Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.
除了要连接的响应之外，200响应始终具有有效负载，尽管源服务器可能会生成长度为零的有效负载主体。如果不需要有效负载，则源服务器应该改为发送204（无内容）。对于CONNECT，不允许有效负载，因为成功的结果是一个隧道，它在200响应头部分之后立即开始。
A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，200响应是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.
201（已创建）状态代码表示请求已完成，并导致创建一个或多个新资源。由请求创建的主要资源由响应中的位置标头字段标识，如果未收到位置字段，则由有效的请求URI标识。
The 201 response payload typically describes and links to the resource(s) created. See Section 7.2 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.
201响应有效载荷通常描述和链接到所创建的资源。参见第7.2节，了解201响应中验证程序标题字段（如ETag和Last Modified）的含义和用途的讨论。
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.
202（已接受）状态代码表示请求已接受处理，但处理尚未完成。请求可能最终会被执行，也可能不会被执行，因为当处理实际发生时，请求可能会被拒绝。HTTP中没有用于从异步操作重新发送状态代码的功能。
The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
202号决议的答复是故意的不明确。它的目的是允许服务器接受其他进程的请求（可能是一个面向批处理的进程，每天只运行一次），而不需要用户代理与服务器的连接持续到进程完成为止。与此响应一起发送的表示应该描述请求的当前状态，并指向（或嵌入）一个状态监视器，该监视器可以向用户提供请求何时完成的估计。
The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 5.7.2 of [RFC7230]). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).
203（非权威信息）状态代码表示请求成功，但通过转换代理（RFC7230的第5.7.2节）已从原始服务器的200（OK）响应修改了附带的有效负载。此状态代码允许代理在应用转换时通知收件人，因为这些信息可能会影响以后有关内容的决策。例如，未来对内容的缓存验证请求可能仅适用于相同的请求路径（通过相同的代理）。
The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [RFC7234]), which has the advantage of being applicable to responses with any status code.
203响应类似于应用214转换的警告代码（RFC7234第5.5节），其优点是适用于任何状态代码的响应。
A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，203响应是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
204（无内容）状态代码表示服务器已成功完成请求，并且响应有效负载正文中没有要发送的其他内容。响应头字段中的元数据指的是应用请求的操作后的目标资源及其选定的表示形式。
For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
例如，如果收到204状态代码以响应PUT请求，并且响应包含ETag头字段，则PUT成功，ETag字段值包含该目标资源的新表示形式的实体标记。
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.
204响应允许服务器指示操作已成功应用于目标资源，同时暗示用户代理不需要离开其当前“文档视图”（如果有）。服务器假定用户代理将根据其自己的接口向其用户提供一些成功的指示，并在响应中应用任何新的或更新的元数据以实现其活动表示。
For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.
例如，204状态代码通常与对应于“保存”操作的文档编辑界面一起使用，使得正在保存的文档仍然可供用户编辑。它还经常与期望自动化数据传输流行的接口一起使用，例如在分布式版本控制系统中。
A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.
204响应由标头字段后的第一个空行终止，因为它不能包含消息正文。
A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，204响应是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.
205（重置内容）状态代码表示服务器已完成请求，并希望用户代理将导致发送请求的“文档视图”重置为从源服务器接收到的原始状态。
This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space,
此响应旨在支持一个通用数据输入用例，其中用户接收支持数据输入的内容（表单、记事本、画布等），在该空间中输入或操作数据，
causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.
导致在请求中提交输入的数据，然后为下一个输入重置数据输入机制，以便用户可以轻松启动另一个输入操作。
Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response: a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0; b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.
由于205状态代码意味着不会提供额外的内容，因此服务器不得在205响应中生成有效负载。换句话说，服务器必须对205响应执行以下操作之一：a）通过包含值为0的内容长度头字段来指示响应的零长度主体；b） 通过包括值为chunked的传输编码头字段和由零长度的单个块组成的消息体，指示响应的零长度有效载荷；或者，c）在发送终止标题部分的空白行后立即关闭连接。
The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If a Location header field (Section 7.1.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request.
3xx（重定向）类状态代码表示用户代理需要采取进一步的操作以满足请求。如果提供了位置头字段（第7.1.2节），则用户代理可以自动将其请求重定向到位置字段值引用的URI，即使不理解特定的状态代码。根据第4.2.1节中的定义，自动重定向需要注意不安全的方法，因为用户可能不希望重定向不安全的请求。
There are several types of redirects:
有几种类型的重定向：
1. Redirects that indicate the resource might be available at a different URI, as provided by the Location field, as in the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect).
1. 指示资源可能在不同URI处可用的重定向，如位置字段提供的，如状态代码301（永久移动）、302（找到）和307（临时重定向）。
2. Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the 300 (Multiple Choices) status code.
2. 提供匹配资源选择的重定向，每个资源都能够表示原始请求目标，如300（多选）状态代码。
3. Redirection to a different resource, identified by the Location field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
3. 重定向到由位置字段标识的不同资源，该资源可以表示对请求的间接响应，如303（请参阅其他）状态代码中所示。
4. Redirection to a previously cached result, as in the 304 (Not Modified) status code.
4. 重定向到以前缓存的结果，如304（未修改）状态代码。
Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect ([RFC1945], Section 9.3). Early user agents split on whether the method applied to the redirect target would be the same as the
注意：在HTTP/1.0中，状态代码301（永久移动）和302（找到）是为第一种重定向类型定义的（[RFC1945]，第9.3节）。早期用户代理根据应用于重定向目标的方法是否与
original request or would be rewritten as GET. Although HTTP originally defined the former semantics for 301 and 302 (to match its original implementation at CERN), and defined 303 (See Other) to match the latter semantics, prevailing practice gradually converged on the latter semantics for 301 and 302 as well. The first revision of HTTP/1.1 added 307 (Temporary Redirect) to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still do method rewriting for 301 and 302; therefore, this specification makes that behavior conformant when the original request is POST.
原始请求或将被重写为GET。虽然HTTP最初为301和302定义了前一种语义（以匹配其在CERN的原始实现），并为后一种语义定义了303（参见其他），但主流实践也逐渐收敛于301和302的后一种语义。HTTP/1.1的第一个修订版添加了307（临时重定向），以指示前面的语义，而不受不同实践的影响。10年后，大多数用户代理仍然对301和302进行方法重写；因此，当原始请求是POST时，此规范使该行为符合要求。
A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
客户端应检测并干预周期性重定向（即“无限”重定向循环）。
Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068], Section 10.3). Content developers need to be aware that some clients might implement such a fixed limitation.
注：本规范的早期版本建议最多五次重定向（[RFC2068]，第10.3节）。内容开发人员需要知道，某些客户端可能会实现这样一个固定的限制。
The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (Section 3.4).
300（多选）状态代码指示目标资源具有多个表示，每个表示都具有其自己的更具体标识符，并且正在提供关于备选方案的信息，以便用户（或用户代理）可以通过将其请求重定向到这些标识符中的一个或多个来选择优选表示。换句话说，服务器希望用户代理参与反应式协商，以根据其需求选择最合适的表示（第3.4节）。
If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.
如果服务器有首选项，则服务器应生成包含首选项的URI引用的位置标头字段。用户代理可以使用位置字段值进行自动重定向。
For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.
对于除HEAD以外的请求方法，服务器应在300响应中生成有效负载，其中包含表示元数据和URI引用的列表，用户或用户代理可从中选择最首选的一个。如果用户代理了解所提供的媒体类型，则可以自动从该列表中进行选择。本规范未定义自动选择的特定格式，因为HTTP试图保持与其有效负载定义的正交性。在实践中，表示是以一些容易解析的格式提供的，这些格式被认为是用户代理可以接受的，如由共享设计或内容协商确定的，或者是以一些普遍接受的超文本格式提供的。
A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，300响应是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields [RFC5988], each with a relationship of "alternate", though deployment is a chicken-and-egg problem.
注意：300状态代码的原始方案将URI头字段定义为提供替代表示的列表，这样它将可用于200、300和406响应，并在响应HEAD方法时传输。然而，由于缺乏部署和语法上的分歧，URI和替代项（后续建议）都被从本规范中删除。可以使用一组链接头字段[RFC5988]来传递列表，每个字段都具有“alternate”关系，尽管部署是一个鸡和蛋的问题。
The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.
301（永久移动）状态代码表示已为目标资源分配了一个新的永久URI，将来对该资源的任何引用都应该使用其中一个附带的URI。具有链接编辑功能的客户端应尽可能自动将对有效请求URI的引用重新链接到服务器发送的一个或多个新引用。
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).
服务器应该在响应中生成一个位置头字段，其中包含新永久URI的首选URI引用。用户代理可以使用位置字段值进行自动重定向。服务器的响应负载通常包含一个简短的超文本注释，其中包含指向新URI的超链接。
Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.
注意：由于历史原因，用户代理可能会将后续请求的请求方法从POST更改为GET。如果不希望出现这种行为，可以使用307（临时重定向）状态代码。
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
301响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.
302（已找到）状态代码表示目标资源临时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续为将来的请求使用有效的请求URI。
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
服务器应该在响应中生成一个位置头字段，其中包含不同URI的URI引用。用户代理可以使用位置字段值进行自动重定向。服务器的响应负载通常包含一个简短的超文本注释，其中包含指向不同URI的超链接。
Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.
注意：由于历史原因，用户代理可能会将后续请求的请求方法从POST更改为GET。如果不希望出现这种行为，可以使用307（临时重定向）状态代码。
The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.
303（参见其他）状态代码指示服务器正在将用户代理重定向到不同的资源，如位置报头字段中的URI所示，其旨在提供对原始请求的间接响应。用户代理可以执行针对该URI的检索请求（如果使用HTTP，则为GET或HEAD请求），该请求也可能被重定向，并将最终结果显示为对原始请求的回答。请注意，位置标头字段中的新URI不被视为等同于有效的请求URI。
This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.
此状态代码适用于任何HTTP方法。它主要用于允许POST操作的输出将用户代理重定向到选定的资源，因为这样做可以以独立于原始请求的形式提供与POST响应相对应的信息，这些信息可以单独识别、标记和缓存。
A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.
303对GET请求的响应表示源服务器没有可由服务器通过HTTP传输的目标资源的表示。但是，位置字段值引用了描述目标资源的资源，因此对该其他资源发出检索请求可能会导致对接收者有用的表示，而不意味着它表示原始目标资源。请注意，关于什么可以表示、什么表示足够以及什么可能是有用的描述等问题的答案不在HTTP的范围之内。
Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field.
除了对HEAD请求的响应外，303响应的表示应该包含一个简短的超文本注释，其中包含指向Location header字段中提供的相同URI引用的超链接。
The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B).
305（使用代理）状态代码是在本规范的早期版本中定义的，现已弃用（附录B）。
The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.
306状态代码在本规范的早期版本中定义，不再使用，并且保留该代码。
The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.
307（临时重定向）状态代码表示目标资源临时驻留在不同的URI下，如果用户代理执行到该URI的自动重定向，则不得更改请求方法。由于重定向会随着时间的推移而改变，因此客户端应该继续使用原始的有效请求URI来处理将来的请求。
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
服务器应该在响应中生成一个位置头字段，其中包含不同URI的URI引用。用户代理可以使用位置字段值进行自动重定向。服务器的响应负载通常包含一个简短的超文本注释，其中包含指向不同URI的超链接。
Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([RFC7238], however, defines the status code 308 (Permanent Redirect) for this purpose).
注意：此状态代码类似于302（Found），只是它不允许将请求方法从POST更改为GET。本规范未定义301（永久移动）的等效副本（但是[RFC7238]为此定义了状态代码308（永久重定向））。
The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.
状态代码的4xx（客户端错误）类表示客户端似乎已出错。除响应HEAD请求外，服务器应发送一个表示，其中包含对错误情况的解释，以及错误是暂时的还是永久性的。这些状态代码适用于任何请求方法。用户代理应向用户显示任何包含的表示。
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
400（错误请求）状态代码表示服务器无法或将不会处理请求，原因是被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性的请求路由）。
The 402 (Payment Required) status code is reserved for future use.
402（需要付款）状态代码保留供将来使用。
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
403（禁止）状态代码表示服务器理解该请求，但拒绝对其进行授权。希望公开请求被禁止原因的服务器可以在响应负载（如果有）中描述该原因。
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
如果请求中提供了身份验证凭据，则服务器认为这些凭据不足以授予访问权限。客户端不应使用相同的凭据自动重复请求。客户端可以使用新的或不同的凭据重复请求。但是，请求可能由于与凭据无关的原因而被禁止。
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
希望“隐藏”当前存在的禁止目标资源的源服务器可能会以404（未找到）的状态代码响应。
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.
404（未找到）状态代码表示源服务器未找到目标资源的当前表示形式，或者不愿意透露存在该表示形式。404状态代码并不表明这种缺乏代表性是暂时的还是永久的；如果源服务器可能通过一些可配置的方式知道状态可能是永久性的，那么410（Gone）状态代码优先于404。
A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
404响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
405（不允许方法）状态代码表示在请求行中接收的方法为源服务器所知，但目标资源不支持。源服务器必须在405响应中生成一个Allow header字段，该响应包含目标资源当前支持的方法的列表。
A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
405响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 5.3), and the server is unwilling to supply a default representation.
根据请求（第5.3节）中接收到的主动协商标头字段，406（不可接受）状态代码表示目标资源没有用户代理可以接受的当前表示，并且服务器不愿意提供默认表示。
The server SHOULD generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 6.4.1.
服务器应该生成一个有效负载，其中包含可用表示特征和相应资源标识符的列表，用户或用户代理可以从中选择最合适的一个。用户代理可以自动从该列表中选择最合适的选项。然而，本规范并未定义第6.4.1节所述的此类自动选择的任何标准。
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.
408（请求超时）状态代码指示服务器在准备等待的时间内没有收到完整的请求消息。服务器应在响应中发送“关闭”连接选项（RFC7230的第6.1节），因为408表示服务器已决定关闭连接，而不是继续等待。如果客户端在传输过程中有未完成的请求，则客户端可以在新连接上重复该请求。
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.
409（冲突）状态代码表示由于与目标资源的当前状态冲突，请求无法完成。此代码用于用户可能能够解决冲突并重新提交请求的情况。服务器应该生成一个有效负载，其中包含足够的信息，以便用户识别冲突的来源。
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.
在响应PUT请求时最有可能发生冲突。例如，如果正在使用版本控制，并且所放置的表示包含对资源的更改，这些更改与先前（第三方）请求所做的更改相冲突，则源服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应表示可能包含有助于根据修订历史合并差异的信息。
The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not
410（已消失）状态代码表示对目标资源的访问在源服务器上不再可用，并且这种情况可能是永久性的。如果源服务器没有
know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.
知道或无法确定该状况是否为永久性，应改用状态代码404（未找到）。
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
410响应主要用于通过通知接收者资源故意不可用以及服务器所有者希望删除指向该资源的远程链接来协助web维护任务。此类活动在有限的时间、促销服务和不再与源服务器站点关联的个人资源中很常见。无需将所有永久不可用的资源标记为“已消失”，也无需将标记保留任何时间长度——这由服务器所有者自行决定。
A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
410响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 3.3.2 of [RFC7230]). The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.
411（需要长度）状态代码表示服务器拒绝接受没有定义内容长度的请求（RFC7230的第3.3.2节）。如果客户端在请求消息中添加了包含消息正文长度的有效内容长度头字段，则客户端可能会重复该请求。
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
413（负载过大）状态代码表示服务器拒绝处理请求，因为请求负载大于服务器愿意或能够处理的负载。服务器可能会关闭连接以阻止客户端继续请求。
If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
如果条件是临时的，服务器应该生成一个Retry After标头字段，以指示它是临时的，并且在什么时间之后客户端可以重试。
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client attempting to exploit potential security holes.
414（URI过长）状态代码表示服务器拒绝为请求提供服务，因为请求目标（RFC7230的第5.3节）比服务器愿意解释的长。只有当客户端将POST请求错误地转换为具有长查询信息的GET请求时，当客户端陷入重定向的“黑洞”（例如，指向自身后缀的重定向URI前缀）时，才会出现这种罕见的情况或者当服务器受到试图利用潜在安全漏洞的客户端的攻击时。
A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
414响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
415（不受支持的媒体类型）状态代码指示源服务器拒绝为请求提供服务，因为有效负载的格式不受目标资源上该方法的支持。格式问题可能是由于请求指示的内容类型或内容编码，或者是直接检查数据的结果。
The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field (Section 5.1.1) could not be met by at least one of the inbound servers.
417（预期失败）状态代码表示请求的预期标头字段（第5.1.1节）中给出的预期至少一个入站服务器无法满足。
The 426 (Upgrade Required) status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 6.7 of [RFC7230]).
426（需要升级）状态代码表示服务器拒绝使用当前协议执行请求，但在客户端升级到其他协议后可能愿意这样做。服务器必须在426响应中发送一个Upgrade header字段，以指示所需的协议（RFC7230的第6.7节）。
Example:
例子：
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol.
此服务需要使用HTTP/3.0协议。
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent
状态代码的5xx（服务器错误）类表示服务器意识到自己出错或无法执行请求的方法。除响应HEAD请求外，服务器应发送一个表示，其中包含对错误情况的解释，以及它是临时的还是永久的
condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
条件用户代理应向用户显示任何包含的表示。这些响应代码适用于任何请求方法。
The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
500（内部服务器错误）状态代码表示服务器遇到意外情况，无法满足请求。
The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
501（未实现）状态代码表示服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且无法为任何资源支持该方法时，这是适当的响应。
A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
501响应在默认情况下是可缓存的；i、 e.，除非方法定义或显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.
502（坏网关）状态代码表示服务器在充当网关或代理时，在尝试完成请求时从其访问的入站服务器接收到无效响应。
The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
503（服务不可用）状态代码表示由于临时过载或计划维护，服务器当前无法处理请求，这可能会在延迟一段时间后得到缓解。服务器可能会发送一个Retry After标头字段（第7.1.3节），以建议客户端在重试请求之前等待的适当时间。
Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.
注意：503状态代码的存在并不意味着服务器在过载时必须使用它。有些服务器可能只是拒绝连接。
The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.
504（网关超时）状态代码表示服务器在充当网关或代理时，没有从其需要访问的上游服务器接收到及时响应以完成请求。
The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in Section 2.6 of [RFC7230], other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.
505（HTTP版本不受支持）状态代码表示服务器不支持或拒绝支持请求消息中使用的HTTP主版本。如[RFC7230]第2.6节所述，服务器表示无法或不愿意使用与客户机相同的主版本完成请求，除了此错误消息。服务器应该为505响应生成一个表示，描述为什么不支持该版本以及该服务器支持哪些其他协议。
The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the target resource, or about related resources.
响应头字段允许服务器传递有关响应的附加信息，超出状态行中的位置。这些标题字段提供有关服务器、进一步访问目标资源或相关资源的信息。
Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the semantics of the request method and/or response status code.
虽然每个响应头字段都有一个定义的含义，但一般来说，可以通过请求方法和/或响应状态代码的语义进一步细化精确的语义。
Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.
响应头字段可以提供控制数据，以补充状态代码、指示缓存或指示客户机下一步去哪里。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Age | Section 5.1 of [RFC7234] |
| Cache-Control | Section 5.2 of [RFC7234] |
| Expires | Section 5.3 of [RFC7234] |
| Date | Section 7.1.1.2 |
| Location | Section 7.1.2 |
| Retry-After | Section 7.1.3 |
| Vary | Section 7.1.4 |
| Warning | Section 5.5 of [RFC7234] |
+-------------------+--------------------------+
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Age | Section 5.1 of [RFC7234] |
| Cache-Control | Section 5.2 of [RFC7234] |
| Expires | Section 5.3 of [RFC7234] |
| Date | Section 7.1.1.2 |
| Location | Section 7.1.2 |
| Retry-After | Section 7.1.3 |
| Vary | Section 7.1.4 |
| Warning | Section 5.5 of [RFC7234] |
+-------------------+--------------------------+
Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322].
在1995年之前，服务器通常使用三种不同的格式来传递时间戳。为了与旧的实现兼容，这里定义了这三种实现。首选格式是互联网消息格式[RFC5322]使用的日期和时间规范的固定长度和单区域子集。
HTTP-date = IMF-fixdate / obs-date
HTTP-date = IMF-fixdate / obs-date
An example of the preferred format is
首选格式的一个示例是
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Examples of the two obsolete formats are
这两种过时格式的示例如下：
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
A recipient that parses a timestamp value in an HTTP header field MUST accept all three HTTP-date formats. When a sender generates a header field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format.
解析HTTP标头字段中的时间戳值的收件人必须接受所有三种HTTP日期格式。当发送方生成包含一个或多个定义为HTTP date的时间戳的标题字段时，发送方必须以IMF fixdate格式生成这些时间戳。
An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC. A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clock to UTC.
HTTP日期值将时间表示为协调世界时（UTC）的实例。前两种格式用格林威治标准时间的三个字母缩写表示UTC，“GMT”是UTC名称的前身；asctime格式的值假定为UTC格式。从本地时钟生成HTTP日期值的发送方应该使用NTP（[RFC5905]）或类似协议将其时钟与UTC同步。
Preferred format:
首选格式：
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322]
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year ; e.g., 02 Jun 1982
date1=日SP月SP年；e、 g.，1982年6月2日
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive
GMT = %x47.4D.54 ; "GMT", case-sensitive
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second)
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT minute = 2DIGIT second = 2DIGIT
小时=2数字分钟=2数字秒=2数字
Obsolete formats:
过时格式：
obs-date = rfc850-date / asctime-date
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT date2 = day "-" month "-" 2DIGIT ; e.g., 02-Jun-82
rfc850日期=日-name-l，“SP日期2 SP当日时间SP GMT日期2=日“-”月“-”2数字；e、 g.，1982年6月2日
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) ; e.g., Jun 2
asctime date=日期名称SP date3 SP日期时间SP年份日期3=月份SP（2DIGIT/（SP 1DIGIT））；e、 g.，6月2日
HTTP-date is case sensitive. A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of day-name, day, month, year, and time-of-day are the same as those defined for the Internet Message Format constructs with the corresponding name ([RFC5322], Section 3.3).
HTTP日期区分大小写。发送方不能在HTTP日期中生成超出语法中指定为SP的额外空格。日名称、日、月、年和日时间的语义与为具有相应名称的Internet消息格式构造定义的语义相同（[RFC5322]，第3.3节）。
Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits.
使用两位数年份的rfc850日期格式的时间戳值的接收者必须将未来超过50年的时间戳解释为表示过去最后两位数相同的最近一年。
Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format.
除非字段定义另有限制，否则鼓励时间戳值的接收者在解析时间戳时保持健壮。例如，偶尔会通过HTTP从非HTTP源转发消息，该源可能会生成由Internet消息格式定义的任何日期和时间规范。
Note: HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Implementations are not required to use these formats for user presentation, request logging, etc.
注意：日期/时间戳格式的HTTP要求仅适用于它们在协议流中的使用。实现不需要将这些格式用于用户表示、请求日志记录等。
The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as defined in Section 7.1.1.1.
“日期”标题字段表示消息发起的日期和时间，与[RFC5322]第3.6.1节中定义的发起日期字段（原始日期）具有相同的语义。字段值是HTTP日期，如第7.1.1.1节所定义。
Date = HTTP-date
Date = HTTP-date
An example is
例如
Date: Tue, 15 Nov 1994 08:12:31 GMT
Date: Tue, 15 Nov 1994 08:12:31 GMT
When a Date header field is generated, the sender SHOULD generate its field value as the best available approximation of the date and time of message generation. In theory, the date ought to represent the moment just before the payload is generated. In practice, the date can be generated at any time during message origination.
生成日期标头字段时，发件人应生成其字段值，作为消息生成日期和时间的最佳近似值。理论上，日期应该代表有效载荷产生之前的时刻。实际上，可以在消息发起期间的任何时间生成日期。
An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance in Coordinated Universal Time. An origin server MAY send a Date header field if the response is in the 1xx (Informational) or 5xx (Server Error) class of status codes. An origin server MUST send a Date header field in all other cases.
如果原始服务器没有能够在协调通用时间中提供当前实例合理近似值的时钟，则它不得发送日期标头字段。如果响应属于1x（信息）或5xx（服务器错误）状态代码类别，则源服务器可能会发送日期标头字段。在所有其他情况下，源服务器必须发送日期标头字段。
A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream.
具有接收不带日期标头字段的响应消息的时钟的收件人必须记录接收该消息的时间，如果消息被缓存或转发到下游，则必须将相应的日期标头字段附加到消息的标头部分。
A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server. For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks.
用户代理可以在请求中发送日期头字段，但通常不会这样做，除非相信它可以向服务器传递有用的信息。例如，如果期望服务器根据用户代理和服务器时钟之间的差异调整其对用户请求的解释，则HTTP的自定义应用程序可能会传递一个日期。
The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.
“Location”标题字段在一些响应中用于引用与响应相关的特定资源。关系的类型由请求方法和状态代码语义的组合定义。
Location = URI-reference
Location = URI-reference
The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).
字段值由单个URI引用组成。当它具有相对引用的形式时（[RFC3986]，第4.2节），通过根据有效请求URI解析它来计算最终值（[RFC3986]，第5节）。
For 201 (Created) responses, the Location value refers to the primary resource created by the request. For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request.
对于201（已创建）响应，位置值指由请求创建的主资源。对于3xx（重定向）响应，位置值指用于自动重定向请求的首选目标资源。
If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any).
如果3xx（重定向）响应中提供的位置值没有片段组件，则用户代理必须处理重定向，就像该值继承用于生成请求目标的URI引用的片段组件一样（即，重定向继承原始引用的片段，如果有）。
For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field:
例如，为URI引用生成的GET请求“http://www.example.org/~tim“可能会导致包含标题字段的303（请参阅其他）响应：
Location: /People.html#tim
Location: /People.html#tim
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim"
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim"
Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field:
同样，为URI引用生成GET请求“http://www.example.org/index.html#larry“可能会导致包含标题字段的301（永久移动）响应：
Location: http://www.example.net/index.html
Location: http://www.example.net/index.html
which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier.
这表明用户代理重定向到“http://www.example.net/index.html#larry，保留原始片段标识符。
There are circumstances in which a fragment identifier in a Location value would not be appropriate. For example, the Location header field in a 201 (Created) response is supposed to provide a URI that is specific to the created resource.
在某些情况下，位置值中的片段标识符是不合适的。例如，201（已创建）响应中的位置头字段应该提供特定于已创建资源的URI。
Note: Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate or define such processing, but does allow it for the sake of robustness.
注意：某些收件人尝试从无效URI引用的位置字段恢复。本规范不强制或定义此类处理，但出于稳健性考虑，允许进行此类处理。
Note: The Content-Location header field (Section 3.1.4.2) differs from Location in that the Content-Location refers to the most specific resource corresponding to the enclosed representation. It is therefore possible for a response to contain both the Location and Content-Location header fields.
注：内容位置标题字段（第3.1.4.2节）与位置的不同之处在于，内容位置指的是与所附表示相对应的最具体的资源。因此，响应可能同时包含位置和内容位置头字段。
Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request. When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client. When sent with any 3xx (Redirection) response, Retry-After indicates the minimum time that the user agent is asked to wait before issuing the redirected request.
服务器发送“重试后”标题字段，以指示用户代理在发出后续请求之前应该等待多长时间。当发送503（服务不可用）响应时，Retry After指示服务预计对客户端不可用的时间。当与任何3xx（重定向）响应一起发送时，Retry After表示在发出重定向请求之前要求用户代理等待的最短时间。
The value of this field can be either an HTTP-date or a number of seconds to delay after the response is received.
此字段的值可以是HTTP日期，也可以是收到响应后的延迟秒数。
Retry-After = HTTP-date / delay-seconds
Retry-After = HTTP-date / delay-seconds
A delay-seconds value is a non-negative decimal integer, representing time in seconds.
延迟秒值是非负十进制整数，以秒为单位表示时间。
delay-seconds = 1*DIGIT
delay-seconds = 1*DIGIT
Two examples of its use are
使用它的两个例子是
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
在后一个示例中，延迟为2分钟。
The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response. The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive).
响应中的“Vary”头字段描述了除了方法、主机头字段和请求目标之外，请求消息的哪些部分可能会影响源服务器选择和表示此响应的过程。该值由单个星号（“*”）或标题字段名列表组成（不区分大小写）。
Vary = "*" / 1#field-name
Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address). A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server. A proxy MUST NOT generate a Vary field with a "*" value.
变量字段值“*”表示有关请求的任何内容都可能在选择响应表示中发挥作用，可能包括消息语法之外的元素（例如，客户端的网络地址）。如果不将请求转发到源服务器，收件人将无法确定此响应是否适用于以后的请求。代理不能生成带有“*”值的Vary字段。
A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation. The potential selecting header fields are not limited to those defined by this specification.
由逗号分隔的名称列表组成的Vary字段值表示命名请求标头字段（称为selecting header字段）可能在选择表示中起作用。潜在的选择标头字段不限于本规范定义的字段。
For example, a response that contains
例如，包含
Vary: accept-encoding, accept-language
变化：接受编码，接受语言
indicates that the origin server might have used the request's Accept-Encoding and Accept-Language fields (or lack thereof) as determining factors while choosing the content for this response.
指示在选择此响应的内容时，源服务器可能已使用请求的接受编码和接受语言字段（或缺少这些字段）作为确定因素。
An origin server might send Vary with a list of fields for two purposes:
出于两个目的，源服务器可能会发送不同的字段列表：
1. To inform cache recipients that they MUST NOT use this response to satisfy a later request unless the later request has the same values for the listed fields as the original request (Section 4.1 of [RFC7234]). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
1. 通知缓存收件人不得使用此响应来满足后续请求，除非后续请求的列出字段值与原始请求相同（RFC7234第4.1节）。换句话说，Vary扩展将新请求与存储的缓存项匹配所需的缓存键。
2. To inform user agent recipients that this response is subject to content negotiation (Section 5.3) and that a different representation might be sent in a subsequent request if additional parameters are provided in the listed header fields (proactive negotiation).
2. 通知用户代理收件人此响应受内容协商的约束（第5.3节），并且如果在列出的标题字段中提供了其他参数，则可能会在后续请求中发送不同的表示（主动协商）。
An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency. For example, there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (Section 4.2 of [RFC7235]). Likewise, an origin server might use Cache-Control directives (Section 5.2 of [RFC7234]) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
当源服务器用于选择表示的算法根据请求消息的不同方面（而不是方法和请求目标）而变化时，源服务器应发送一个Vary头字段，除非不能跨越差异，或者源服务器已特意配置为防止缓存透明。例如，不需要以Vary格式发送授权字段名称，因为跨用户的重用受字段定义的限制（RFC7235的第4.2节）。同样，如果源服务器认为差异不如Vary对缓存的影响的性能成本显著，则可以使用缓存控制指令（RFC7234的第5.2节）替代Vary。
Validator header fields convey metadata about the selected representation (Section 3). In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response. Note that, depending on the status code semantics, the selected representation for a given response is not necessarily the same as the representation enclosed as response payload.
验证程序头字段传递有关所选表示的元数据（第3节）。在响应安全请求时，验证器字段描述源服务器在处理响应时选择的表示形式。请注意，根据状态代码语义，为给定响应选择的表示不一定与作为响应负载包含的表示相同。
In a successful response to a state-changing request, validator fields describe the new representation that has replaced the prior selected representation as a result of processing the request.
在对状态更改请求的成功响应中，验证程序字段描述作为处理请求的结果而替换先前选择的表示的新表示。
For example, an ETag header field in a 201 (Created) response communicates the entity-tag of the newly created resource's representation, so that it can be used in later conditional requests to prevent the "lost update" problem [RFC7232].
例如，201（已创建）响应中的ETag头字段传递新创建资源表示的实体标记，以便在以后的条件请求中使用它来防止“丢失更新”问题[RFC7232]。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| ETag | Section 2.3 of [RFC7232] |
| Last-Modified | Section 2.2 of [RFC7232] |
+-------------------+--------------------------+
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| ETag | Section 2.3 of [RFC7232] |
| Last-Modified | Section 2.2 of [RFC7232] |
+-------------------+--------------------------+
Authentication challenges indicate what mechanisms are available for the client to provide authentication credentials in future requests.
身份验证挑战指示客户端在将来的请求中提供身份验证凭据的机制。
+--------------------+--------------------------+
| Header Field Name | Defined in... |
+--------------------+--------------------------+
| WWW-Authenticate | Section 4.1 of [RFC7235] |
| Proxy-Authenticate | Section 4.3 of [RFC7235] |
+--------------------+--------------------------+
+--------------------+--------------------------+
| Header Field Name | Defined in... |
+--------------------+--------------------------+
| WWW-Authenticate | Section 4.1 of [RFC7235] |
| Proxy-Authenticate | Section 4.3 of [RFC7235] |
+--------------------+--------------------------+
The remaining response header fields provide more information about the target resource for potential use in later requests.
其余的响应头字段提供有关目标资源的更多信息，以便在以后的请求中使用。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Accept-Ranges | Section 2.3 of [RFC7233] |
| Allow | Section 7.4.1 |
| Server | Section 7.4.2 |
+-------------------+--------------------------+
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Accept-Ranges | Section 2.3 of [RFC7233] |
| Allow | Section 7.4.1 |
| Server | Section 7.4.2 |
+-------------------+--------------------------+
The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.
“Allow”头字段列出了目标资源支持的方法集。此字段的用途严格来说是通知收件人与资源关联的有效请求方法。
Allow = #method
Allow = #method
Example of use:
使用示例：
Allow: GET, HEAD, PUT
允许：获得、头部、放置
The actual set of allowed methods is defined by the origin server at the time of each request. An origin server MUST generate an Allow field in a 405 (Method Not Allowed) response and MAY do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in a 405 response if the resource has been temporarily disabled by configuration.
实际允许的方法集由源服务器在每次请求时定义。源服务器必须在405（不允许方法）响应中生成允许字段，并且可以在任何其他响应中生成允许字段。空的Allow字段值表示资源不允许任何方法，如果资源已被配置临时禁用，则405响应中可能会出现这种情况。
A proxy MUST NOT modify the Allow header field -- it does not need to understand all of the indicated methods in order to handle them according to the generic message handling rules.
代理不能修改Allow header字段——它不需要理解所有指示的方法，以便根据通用消息处理规则处理它们。
The "Server" header field contains information about the software used by the origin server to handle the request, which is often used by clients to help identify the scope of reported interoperability problems, to work around or tailor requests to avoid particular server limitations, and for analytics regarding server or operating system use. An origin server MAY generate a Server field in its responses.
“服务器”标题字段包含有关源服务器用于处理请求的软件的信息，客户端通常使用该软件来帮助确定报告的互操作性问题的范围，解决或调整请求以避免特定的服务器限制，以及进行有关服务器或操作系统使用的分析。源服务器可以在其响应中生成服务器字段。
Server = product *( RWS ( product / comment ) )
Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), which together identify the origin server software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists of a name and optional version, as defined in Section 5.5.3.
服务器字段值由一个或多个产品标识符组成，每个标识符后面都有零个或多个注释（RFC7230）第3.2节），这些注释共同标识原始服务器软件及其重要子产品。按照惯例，产品标识符按其重要性的降序排列，用于标识源服务器软件。每个产品标识符由名称和可选版本组成，如第5.5.3节所定义。
Example:
例子：
Server: CERN/3.0 libwww/2.17
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed Server field values increase response latency and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes.
源服务器不应生成包含不必要的细粒度细节的服务器字段，并且应限制第三方添加子产品。过长且详细的服务器字段值会增加响应延迟，并可能暴露内部实现细节，这可能使攻击者（稍微）更容易发现和利用已知的安全漏洞。
The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the namespace for the request method token (Section 4). The method registry has been created and is now maintained at <http://www.iana.org/assignments/http-methods>.
“超文本传输协议（HTTP）方法注册表”定义了请求方法令牌的名称空间（第4节）。方法注册表已创建，现在维护在<http://www.iana.org/assignments/http-methods>.
HTTP method registrations MUST include the following fields:
HTTP方法注册必须包括以下字段：
o Method Name (see Section 4)
o 方法名称（参见第4节）
o Safe ("yes" or "no", see Section 4.2.1)
o 安全（“是”或“否”，见第4.2.1节）
o Idempotent ("yes" or "no", see Section 4.2.2)
o 幂等元（“是”或“否”，见第4.2.2节）
o Pointer to specification text
o 指向规范文本的指针
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
添加到此命名空间的值需要IETF审查（请参见[RFC5226]，第4.1节）。
Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
标准化方法是通用的；也就是说，它们可能适用于任何资源，而不仅仅是一种特定的媒体类型、资源类型或应用程序。因此，新方法最好注册在一个文档中，而不是特定于单个应用程序或数据格式，因为正交技术应该得到正交规范。
Since message parsing (Section 3.3 of [RFC7230]) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a value of "0".
由于消息解析（RFC7230的第3.3节）需要独立于方法语义（除了对HEAD的响应），因此新方法的定义不能更改解析算法或禁止在请求或响应消息上存在消息体。新方法的定义可以通过要求值为“0”的内容长度头字段来指定只允许零长度的消息正文。
A new method definition needs to indicate whether it is safe (Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.3), what semantics are to be associated with the payload body if any is present in the request and what refinements the method makes to header field or status code semantics. If the new method is cacheable, its definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy a subsequent request. The new method ought to describe whether it can be made conditional (Section 5.2) and, if so, how a server responds when the condition is false. Likewise, if the new method might have some use for partial response semantics ([RFC7233]), it ought to document this, too.
一个新的方法定义需要指出它是否安全（第4.2.1节）、幂等（第4.2.2节）、可缓存（第4.2.3节）、如果请求中存在有效负载主体，将与之关联的语义以及该方法对头字段或状态代码语义进行的改进。如果新方法是可缓存的，那么它的定义应该描述缓存如何以及在什么条件下存储响应并使用它来满足后续请求。新方法应该描述是否可以将其设置为有条件的（第5.2节），如果可以，则描述当条件为false时服务器如何响应。类似地，如果新方法可能对部分响应语义（[RFC7233]）有一些用处，那么它也应该记录这一点。
Note: Avoid defining a method name that starts with "M-", since that prefix might be misinterpreted as having the semantics assigned to it by [RFC2774].
注意：避免定义以“M-”开头的方法名，因为该前缀可能被误解为具有[RFC2774]为其指定的语义。
The "Hypertext Transfer Protocol (HTTP) Method Registry" has been populated with the registrations below:
“超文本传输协议（HTTP）方法注册表”已填充以下注册：
+---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+
+---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines the namespace for the response status-code token (Section 6). The status code registry is maintained at <http://www.iana.org/assignments/http-status-codes>.
“超文本传输协议（HTTP）状态代码注册表”定义了响应状态代码令牌的名称空间（第6节）。状态代码注册表维护在<http://www.iana.org/assignments/http-status-codes>.
This section replaces the registration procedure for HTTP Status Codes previously defined in Section 7.1 of [RFC2817].
本节取代[RFC2817]第7.1节中先前定义的HTTP状态代码的注册程序。
A registration MUST include the following fields:
注册必须包括以下字段：
o Status Code (3 digits)
o 状态代码（3位）
o Short Description
o 简短描述
o Pointer to specification text
o 指向规范文本的指针
Values to be added to the HTTP status code namespace require IETF Review (see [RFC5226], Section 4.1).
要添加到HTTP状态码命名空间的值需要IETF审查（参见[RFC5226]，第4.1节）。
When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application.
当需要表示当前状态代码未定义的响应的语义时，可以注册新的状态代码。状态代码是通用的；它们可能适用于任何资源，而不仅仅是一种特定的媒体类型、资源类型或HTTP应用程序。因此，最好将新的状态代码注册到不特定于单个应用程序的文档中。
New status codes are required to fall under one of the categories defined in Section 6. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can mandate a zero-length payload body.
新的状态代码必须属于第6节定义的类别之一。为了允许现有解析器处理响应消息，新的状态代码不能禁止有效负载，尽管它们可以强制使用零长度的有效负载主体。
Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely.
尚未广泛实施的新身份代码提案应避免为该代码分配特定编号，直到达成明确共识，该代码将被注册；相反，早期草稿可以使用诸如“4NN”或“3N0”之类的符号。。“3N9”，用于指示建议状态代码的类别，而不会过早使用数字。
The definition of a new status code ought to explain the request conditions that would cause a response containing that status code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined when used with the new status code).
新状态代码的定义应解释将导致包含该状态代码的响应的请求条件（例如，请求头字段和/或方法的组合）以及对响应头字段的任何依赖关系（例如，哪些字段是必需的，哪些字段可以修改语义，以及在与新状态代码一起使用时，哪些标题字段语义会进一步细化）。
The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior. See [RFC7234] for more information.
新状态代码的定义应该指定它是否可缓存。注意，如果出现的响应具有明确的新鲜度信息，则可以缓存所有状态代码；但是，允许缓存定义为可缓存的状态代码，而无需显式的新鲜度信息。同样，状态代码的定义可以对缓存行为施加约束。有关更多信息，请参阅[RFC7234]。
Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified resource (Section 3.1.4.1).
最后，新状态代码的定义应表明有效负载是否与已识别资源存在任何隐含关联（第3.1.4.1节）。
The status code registry has been updated with the registrations below:
已使用以下注册更新状态代码注册表：
+-------+-------------------------------+----------------+
| Value | Description | Reference |
+-------+-------------------------------+----------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+
+-------+-------------------------------+----------------+
| Value | Description | Reference |
+-------+-------------------------------+----------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+
HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/message-headers>, as defined by [BCP90].
HTTP头字段在位于的“消息头”注册表中注册<http://www.iana.org/assignments/message-headers>，定义见[BCP90]。
Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, or the connection (i.e., control data). See Section 3.2 of [RFC7230] for a general definition of header field syntax in HTTP messages.
标头字段是键：值对，可用于传递有关消息、其有效负载、目标资源或连接（即控制数据）的数据。有关HTTP消息中标头字段语法的一般定义，请参见[RFC7230]的第3.2节。
The requirements for header field names are defined in [BCP90].
标题字段名称的要求在[BCP90]中定义。
Authors of specifications defining new fields are advised to keep the name as short as practical and not to prefix the name with "X-" unless the header field will never be used on the Internet. (The "X-" prefix idiom has been extensively misused in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see [BCP178] for further information).
建议定义新字段的规范的作者将名称尽可能短，并且不要在名称前加上“X-”，除非标题字段永远不会在Internet上使用。（在实践中，“X-”前缀习惯用法被广泛误用；它仅用于避免专有软件或内部网处理中的名称冲突，因为前缀将确保私有名称不会与新注册的互联网名称发生冲突；有关更多信息，请参阅[BCP178]）。
New header field values typically have their syntax defined using ABNF ([RFC5234]), using the extension defined in Section 7 of [RFC7230] as necessary, and are usually constrained to the range of US-ASCII characters. Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].
新的标题字段值通常使用ABNF（[RFC5234]）定义语法，必要时使用[RFC7230]第7节中定义的扩展名，并且通常限制在US-ASCII字符范围内。需要较大字符范围的标题字段可以使用[RFC5987]中定义的编码。
Leading and trailing whitespace in raw field values is removed upon field parsing (Section 3.2.4 of [RFC7230]). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such as quoted-string (Section 3.2.6 of [RFC7230]).
原始字段值中的前导和尾随空格在字段解析时被删除（RFC7230的第3.2.4节）。如果值中的前导或尾随空格很重要，则字段定义必须使用容器语法，如引号字符串（RFC7230的第3.2.6节）。
Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production.
由于逗号（“，”）用作字段值之间的通用分隔符，因此如果字段值中允许逗号，则需要小心处理。通常，可能包含逗号的组件使用带引号的字符串ABNF production使用双引号进行保护。
For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like these:
例如，文本日期和URI（其中任何一个都可能包含逗号）可以安全地包含在如下字段值中：
Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-quotes will likely cause unnecessary confusion.
请注意，双引号分隔符几乎总是用于带引号的字符串生成；在双引号中使用不同的语法可能会导致不必要的混淆。
Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in Section 3.1.1.5). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for it (for an example, see the notes on parameter handling for media types in Section 3.1.1.1).
许多标题字段使用的格式包括（不区分大小写）命名参数（例如，第3.1.1.5节中定义的内容类型）。允许参数值同时使用unquoted（标记）和quoted（带引号的字符串）语法，使收件人能够使用现有的解析器组件。当允许这两种形式时，参数值的含义应该独立于用于它的语法（例如，请参阅第3.1.1.1节中有关媒体类型的参数处理的注释）。
Authors of specifications defining new header fields are advised to consider documenting:
定义新标题字段的规范作者建议考虑文档化：
o Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).
o 字段是单个值还是可以是列表（用逗号分隔；请参见[RFC7230]第3.2节）。
If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).
如果不使用列表语法，请记录如何处理字段多次出现的消息（一个合理的默认设置是忽略字段，但这可能并不总是正确的选择）。
Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the field's definition not allowing the list syntax. A robust format enables recipients to discover these situations (good example: "Content-Type", as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI).
请注意，中介体和软件库可能会将多个头字段实例合并为一个实例，尽管该字段的定义不允许使用列表语法。健壮的格式使收件人能够发现这些情况（好的示例：“内容类型”，因为逗号只能出现在带引号的字符串中；坏的示例：“位置”，因为逗号可以出现在URI中）。
o Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method, etc.
o 在什么条件下可以使用标题字段；e、 例如，仅在响应或请求中，在所有消息中，仅在对特定请求方法的响应中，等等。
o Whether the field should be stored by origin servers that understand it upon a PUT request.
o 字段是否应由在PUT请求时理解它的源服务器存储。
o Whether the field semantics are further refined by the context, such as by existing request methods or status codes.
o 字段语义是否由上下文进一步细化，例如通过现有的请求方法或状态代码。
o Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]).
o 在连接头字段中列出字段名是否合适（即，如果头字段是逐跳的；请参阅[RFC7230]的第6.1节）。
o Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
o 在什么条件下允许中介插入、删除或修改字段的值。
o Whether it is appropriate to list the field-name in a Vary response header field (e.g., when the request header field is used by an origin server's content selection algorithm; see Section 7.1.4).
o 是否适合在不同响应标头字段中列出字段名称（例如，当原始服务器的内容选择算法使用请求标头字段时；请参阅第7.1.4节）。
o Whether the header field is useful or allowable in trailers (see Section 4.1 of [RFC7230]).
o 标题字段在拖车中是否有用或允许（见[RFC7230]第4.1节）。
o Whether the header field ought to be preserved across redirects.
o 是否应跨重定向保留标头字段。
o Whether it introduces any additional security considerations, such as disclosure of privacy-related data.
o 它是否引入了任何额外的安全注意事项，如披露隐私相关数据。
The "Message Headers" registry has been updated with the following permanent registrations:
“邮件标题”注册表已更新为以下永久注册：
+-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+
+-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+
The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
上述注册的变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
The "HTTP Content Coding Registry" defines the namespace for content coding names (Section 4.2 of [RFC7230]). The content coding registry is maintained at <http://www.iana.org/assignments/http-parameters>.
“HTTP内容编码注册表”定义了内容编码名称的名称空间（见[RFC7230]第4.2节）。内容编码注册表维护在<http://www.iana.org/assignments/http-parameters>.
Content coding registrations MUST include the following fields:
内容编码注册必须包括以下字段：
o Name
o 名称
o Description
o 描述
o Pointer to specification text
o 指向规范文本的指针
Names of content codings MUST NOT overlap with names of transfer codings (Section 4 of [RFC7230]), unless the encoding transformation is identical (as is the case for the compression codings defined in Section 4.2 of [RFC7230]).
内容编码的名称不得与传输编码的名称重叠（参见[RFC7230]第4节），除非编码转换相同（参见[RFC7230]第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 content coding defined in this section.
添加到此名称空间的值需要IETF审查（见[RFC5226]第4.1节），并且必须符合本节中定义的内容编码目的。
The "HTTP Content Coding Registry" has been updated with the registrations below:
“HTTP内容编码注册表”已更新为以下注册：
+----------+----------------------------------------+---------------+
| Name | Description | Reference |
+----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | |
+----------+----------------------------------------+---------------+
+----------+----------------------------------------+---------------+
| Name | Description | Reference |
+----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | |
+----------+----------------------------------------+---------------+
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. Considerations related to message syntax, parsing, and routing are discussed in Section 9 of [RFC7230].
本节旨在告知开发人员、信息提供商和用户与HTTP语义及其在Internet上传输信息的使用相关的已知安全问题。[RFC7230]第9节讨论了与消息语法、解析和路由相关的注意事项。
The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent
下面列出的考虑事项并不详尽。与HTTP语义相关的大多数安全问题都是关于保护服务器端应用程序（HTTP接口后面的代码）、保护用户代理的安全
processing of payloads received via HTTP, or secure use of the Internet in general, rather than security of the protocol. Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]).
处理通过HTTP接收的有效负载，或安全地使用Internet，而不是协议的安全性。各种组织都维护有关Web应用程序安全性的当前研究的主题信息和链接（例如[OWASP]）。
Origin servers frequently make use of their local file system to manage the mapping from effective request URI to resource representations. Most file systems are not designed to protect against malicious file or path names. Therefore, an origin server needs to avoid accessing names that have a special significance to the system when mapping the request target to files, folders, or directories.
源服务器经常使用其本地文件系统来管理从有效请求URI到资源表示的映射。大多数文件系统的设计目的都不是为了防止恶意文件或路径名。因此，在将请求目标映射到文件、文件夹或目录时，源服务器需要避免访问对系统具有特殊意义的名称。
For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one, and they use specially named paths or file names to send data to system devices. Similar naming conventions might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization of case-insensitive names.
例如，UNIX、Microsoft Windows和其他操作系统使用“.”作为路径组件，以指示高于当前目录级别的目录级别，并使用特殊命名的路径或文件名向系统设备发送数据。其他类型的存储系统中可能存在类似的命名约定。同样，本地存储系统在处理无效或意外字符、重新组合分解的字符以及不区分大小写的名称的大小写规范化时，倾向于用户友好而不是安全性。
Attacks based on such special names tend to focus on either denial-of-service (e.g., telling the server to read from a COM port) or disclosure of configuration and source files that are not meant to be served.
基于此类特殊名称的攻击往往侧重于拒绝服务（例如，告诉服务器从COM端口读取）或泄露不打算提供服务的配置和源文件。
Origin servers often use parameters within the URI as a means of identifying system services, selecting database entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any of the request data elements (method, request-target, header fields, or body) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.
源服务器通常使用URI中的参数作为标识系统服务、选择数据库条目或选择数据源的手段。但是，请求中接收的数据不可信。攻击者可以构造任何请求数据元素（方法、请求目标、头字段或正文），以包含在通过命令调用、语言解释器或数据库接口传递时可能被误解为命令、代码或查询的数据。
For example, SQL injection is a common attack wherein additional query language is inserted within some part of the request-target or header fields (e.g., Host, Referer, etc.). If the received data is used directly within a SELECT statement, the query language might be interpreted as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in spite of being easy to prevent.
例如，SQL注入是一种常见的攻击，其中在请求目标或头字段（例如，主机、引用器等）的某些部分中插入了额外的查询语言。如果接收到的数据直接在SELECT语句中使用，则查询语言可能被解释为数据库命令，而不是简单的字符串值。这种类型的实现漏洞非常常见，尽管很容易预防。
In general, resource implementations ought to avoid use of request data in contexts that are processed or interpreted as instructions. Parameters ought to be compared to fixed strings and acted upon as a result of that comparison, rather than passed through an interface that is not prepared for untrusted data. Received data that isn't based on fixed parameters ought to be carefully filtered or encoded to avoid being misinterpreted.
一般来说，资源实现应该避免在被处理或解释为指令的上下文中使用请求数据。参数应该与固定字符串进行比较，并作为比较的结果进行操作，而不是通过未为不可信数据做好准备的接口进行传递。不基于固定参数的接收数据应仔细过滤或编码，以避免被误解。
Similar considerations apply to request data when it is stored and later processed, such as within log files, monitoring tools, or when included within a data format that allows embedded scripts.
当请求数据被存储并在以后进行处理时，例如在日志文件、监视工具中，或者包含在允许嵌入脚本的数据格式中时，类似的注意事项也适用于请求数据。
Clients are often privy to large amounts of personal information, including both information provided by the user to interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional disclosure of personal information.
客户通常对大量的个人信息保密，包括用户提供的与资源交互的信息（例如，用户的姓名、位置、邮件地址、密码、加密密钥等）和用户随时间的浏览活动信息（例如，历史记录、书签等）。实施需要防止无意中泄露个人信息。
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
URI旨在共享，而不是安全的，即使它们标识了安全的资源。URI通常显示在显示器上，在打印页面时添加到模板中，并存储在各种不受保护的书签列表中。因此，在URI中包含敏感的、个人可识别的或有披露风险的信息是不明智的。
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
服务的作者应该避免使用基于GET的表单来提交敏感数据，因为这些数据将放在请求目标中。许多现有服务器、代理和用户代理在第三方可能看到的位置记录或显示请求目标。这样的服务应该使用基于POST的表单提交。
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. Limitations on the Referer header field are described in Section 5.5.2 to address some of its security considerations.
由于Referer header字段将导致请求的上下文告知目标站点，因此它有可能显示有关用户即时浏览历史的信息以及在引用资源的URI中可能找到的任何个人信息。第5.5.2节描述了Referer header字段的限制，以解决其一些安全问题。
Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a redirect occurs and the original request's fragment identifier is inherited by the new reference in Location (Section 7.1.2), this might have the effect of disclosing one site's fragment to another site. If the first site uses personal information in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block that inheritance.
尽管URI引用中使用的片段标识符不会在请求中发送，但实现者应该知道，它们对于用户代理以及响应后运行的任何扩展或脚本都是可见的。特别是，当发生重定向且原始请求的片段标识符被位置中的新引用继承时（第7.1.2节），这可能会导致将一个站点的片段披露给另一个站点。如果第一个站点在片段中使用个人信息，它应该确保重定向到其他站点时包含（可能是空的）片段组件，以便阻止该继承。
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and Server (Section 7.4.2) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used.
用户代理（第5.5.3节）、Via（第5.7.1节[RFC7230]）和服务器（第7.4.2节）标题字段通常会显示有关各发送方软件系统的信息。理论上，这可以使攻击者更容易利用已知的安全漏洞；实际上，攻击者倾向于尝试所有潜在漏洞，而不管所使用的软件版本如何。
Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header information that might identify hosts behind the firewall. The Via header field allows intermediaries to replace sensitive machine names with pseudonyms.
作为通过网络防火墙的入口的代理应该采取特别的预防措施来传输可能识别防火墙后面主机的头信息。Via标头字段允许中介机构用假名替换敏感机器名。
Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. These characteristics might include information related to its TCP behavior, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time without the corresponding controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints.
浏览器指纹识别是一组技术，用于通过一组独特的特征识别特定的用户代理。这些特征可能包括与其TCP行为、功能和脚本环境相关的信息，尽管这里特别感兴趣的是可能通过HTTP进行通信的一组独特特征。指纹识别被认为是一个隐私问题，因为它可以跟踪用户代理的行为，而不需要用户对其他形式的数据收集（如cookie）进行相应的控制。许多通用用户代理（即Web浏览器）已采取措施减少其指纹。
There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable fingerprinting. The From header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by the user. Likewise, Cookie header fields are deliberately
有许多请求头字段可能会向服务器显示信息，这些信息的唯一性足以启用指纹识别。From头字段是最明显的，尽管预期只有在用户需要自我识别时才会发送From。同样，Cookie头字段也是故意添加的
designed to enable re-identification, so fingerprinting concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
设计用于启用重新识别，因此指纹问题仅适用于cookie被用户代理的配置禁用或限制的情况。
The User-Agent header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation (Section 5.3), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.
用户代理头字段可能包含足够的信息来唯一标识特定设备，通常在与其他特征结合时，尤其是当用户代理发送有关用户系统或扩展的过多详细信息时。但是，用户最不期望的唯一信息源是主动协商（第5.3节），包括Accept、Accept Charset、Accept Encoding和Accept Language标头字段。
In addition to the fingerprinting concern, detailed use of the Accept-Language header field can reveal information the user might consider to be of a private nature. For example, understanding a given language set might be strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites that have been whitelisted, perhaps via interaction after detecting a Vary header field that indicates language negotiation might be useful.
除了指纹的关注之外，接受语言头部字段的详细使用可以揭示用户可能认为是私人性质的信息。例如，理解一个给定的语言集可能与某个特定民族的成员身份密切相关。限制这种隐私损失的一种方法是，用户代理可以在检测到表明语言协商可能有用的Vary头字段后通过交互，省略发送Accept语言（已被列入白名单的站点除外）。
In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter the proactive negotiation header fields in relayed requests.
在使用代理来增强隐私的环境中，用户代理在发送主动协商头字段时应该保守。提供高度标题字段可配置性的通用用户代理应该通知用户如果提供太多细节可能导致的隐私损失。作为一种极端的隐私措施，代理可以过滤中继请求中的主动协商头字段。
See Section 10 of [RFC7230].
见[RFC7230]第10节。
[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月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[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月。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]Phillips，A.，Ed.和M.Davis，Ed.，“语言标记的匹配”，BCP 47，RFC 4647，2006年9月。
[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月。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 6365，2011年9月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年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月。
[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月。
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[BCP178]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
[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月。
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web Applications and Web Services", The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.
[OWASP]van der Stock，A.，Ed.，“构建安全Web应用程序和Web服务指南”，开放Web应用程序安全项目（OWASP）2.0.12005年7月<https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Dissertation, University of California, Irvine, September 2000, <http://roy.gbiv.com/pubs/dissertation/top.htm>.
“Architectural Styles”和“基于网络的软件体系结构设计”，博士论文，加利福尼亚大学，尔湾，2000年9月，<http://roy.gbiv.com/pubs/dissertation/top.htm>.
[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月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，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月。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[RFC2295]Holtman，K.和A.Mutz，“HTTP中的透明内容协商”，RFC 2295，1998年3月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388]Masinter，L.“从表单返回值：多部分/表单数据”，RFC 23881998年8月。
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[RFC2557]Palme，F.，Hopmann，A.，Shelness，N.，和E.Stefferud，“聚合文档的MIME封装，如HTML（MHTML）”，RFC 2557，1999年3月。
[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月。
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP Extension Framework", RFC 2774, February 2000.
[RFC2774]Frystyk，H.，Leach，P.，和S.Lawrence，“HTTP扩展框架”，RFC 27742000年2月。
[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月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[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月。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010.
[RFC5789]Dusseault，L.和J.Snell，“HTTP的补丁方法”，RFC 5789，2010年3月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987]Reschke，J.，“超文本传输协议（HTTP）头字段参数的字符集和语言编码”，RFC 5987，2010年8月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, June 2011.
[RFC6266]Reschke，J.，“超文本传输协议（HTTP）中内容处置头字段的使用”，RFC 6266，2011年6月。
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)", RFC 7238, June 2014.
[RFC7238]Reschke，J.，“超文本传输协议（HTTP）状态代码308（永久重定向）”，RFC 7238，2014年6月。
HTTP/1.1 uses many of the constructs defined for the Internet Message Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] to allow a message body to be transmitted in an open variety of representations and with extensible header fields. However, RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email; hence, HTTP has features that differ from MIME. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
HTTP/1.1使用为Internet消息格式[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]定义的许多结构，允许以开放的各种表示形式和可扩展的头字段传输消息体。然而，RFC 2045只关注电子邮件；HTTP的应用程序有许多不同于电子邮件的特性；因此，HTTP具有不同于MIME的特性。仔细选择这些差异是为了优化二进制连接的性能，允许在使用新媒体类型时有更大的自由度，使日期比较更容易，并承认一些早期HTTP服务器和客户端的做法。
This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to and from strict MIME environments need to be aware of these differences and provide the appropriate conversions where necessary.
本附录描述了HTTP不同于MIME的特定领域。进出严格MIME环境的代理和网关需要了解这些差异，并在必要时提供适当的转换。
HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined in [RFC2045]). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.
HTTP不是MIME兼容协议。但是，消息可以包含单个MIME版本头字段，以指示用于构造消息的MIME协议版本。使用MIME版本头字段表示消息完全符合MIME协议（如[RFC2045]中所定义）。在将HTTP消息导出到严格的MIME环境时，发送方负责确保完全一致性（如果可能）。
MIME requires that an Internet mail body part be converted to canonical form prior to being transferred, as described in Section 4 of [RFC2049]. Section 3.1.1.3 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. [RFC2046] requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content.
MIME要求在传输之前将Internet邮件正文部分转换为规范格式，如[RFC2049]第4节所述。本文件第3.1.1.3节描述了通过HTTP传输时“文本”媒体类型的子类型所允许的格式。[RFC2046]要求具有“文本”类型的内容将换行符表示为CRLF，并禁止在换行符序列之外使用CR或LF。HTTP允许CRLF、bare CR和bare LF指示文本内容中的换行符。
A proxy or gateway from HTTP to a strict MIME environment ought to translate all line breaks within the text media types described in Section 3.1.1.3 of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
从HTTP到严格MIME环境的代理或网关应将本文档第3.1.1.3节中描述的文本媒体类型中的所有换行符转换为RFC 2049标准格式的CRLF。然而，请注意，由于存在内容编码以及HTTP允许使用一些不使用八位字节13和10分别表示CR和LF的字符集，这可能会变得复杂。
Conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
转换将中断应用于原始内容的任何加密校验和，除非原始内容已经是标准格式。因此，对于在HTTP中使用此类校验和的任何内容，建议使用规范形式。
HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to simplify the process of date comparison. Proxies and gateways from other protocols ought to ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
HTTP/1.1使用一组受限制的日期格式（第7.1.1.1节）简化日期比较过程。来自其他协议的代理和网关应确保消息中的任何日期头字段符合HTTP/1.1格式之一，并在必要时重写日期。
MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols ought to either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
MIME不包含任何与HTTP/1.1的内容编码头字段等效的概念。由于这充当媒体类型的修饰符，从HTTP到MIME兼容协议的代理和网关应该在转发消息之前更改内容类型头字段的值或解码表示。（一些互联网邮件内容类型的实验应用程序使用了媒体类型参数“conversions=<Content coding>”来执行与内容编码等效的功能。但是，该参数不是MIME标准的一部分）。
HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP need to remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
HTTP不使用MIME的内容传输编码字段。从MIME兼容协议到HTTP的代理和网关需要在将响应消息传递到HTTP客户端之前删除任何内容传输编码。
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway ought to transform and label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
从HTTP到MIME兼容协议的代理和网关负责确保消息的格式和编码正确，以便在该协议上进行安全传输，其中“安全传输”由所使用协议的限制定义。如果这样做将提高通过目标协议安全传输的可能性，那么这样的代理或网关应该使用适当的内容传输编码来转换和标记数据。
HTTP implementations that share code with MHTML [RFC2557] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transfers message-bodies as
与MHTML[RFC2557]实现共享代码的HTTP实现需要了解MIME行长度限制。因为HTTP没有这个限制，所以HTTP不会折叠长线。由HTTP传输的MHTML消息遵循MHTML的所有约定，包括行长度限制和折叠、规范化等，因为HTTP将消息体作为
payload and, aside from the "multipart/byteranges" type (Appendix A of [RFC7233]), does not interpret the content or any MIME header lines that might be contained therein.
除了“multipart/byteranges”类型（RFC7233的附录A）之外，payload不会解释其中可能包含的内容或任何MIME头行。
The primary changes in this revision have been editorial in nature: extracting the messaging syntax and partitioning HTTP semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication. The conformance language has been revised to clearly target requirements and the terminology has been improved to distinguish payload from representations and representations from resources.
本修订版中的主要更改本质上是编辑性的：提取消息传递语法并将HTTP语义划分为单独的文档，用于核心功能、条件请求、部分请求、缓存和身份验证。对一致性语言进行了修订，以明确目标需求，并对术语进行了改进，以区分有效负载与表示，以及表示与资源。
A new requirement has been added that semantics embedded in a URI be disabled when those semantics are inconsistent with the request method, since this is a common cause of interoperability failure. (Section 2)
添加了一个新的要求，即当URI中嵌入的语义与请求方法不一致时，应禁用这些语义，因为这是互操作性失败的常见原因。（第2节）
An algorithm has been added for determining if a payload is associated with a specific identifier. (Section 3.1.4.1)
添加了一种算法，用于确定有效负载是否与特定标识符相关联。（第3.1.4.1节）
The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says. Likewise, special treatment of ISO-8859-1 has been removed from the Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)
已删除文本媒体类型的默认字符集ISO-8859-1；默认值现在是媒体类型定义所说的任何内容。同样，ISO-8859-1的特殊处理已从接受字符集标题字段中删除。（第3.1.1.3节和第5.3.3节）
The definition of Content-Location has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support and the undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 3.1.4.2)
内容位置的定义已更改为不再影响用于解析相对URI引用的基本URI，这是由于实现支持较差以及可能中断内容协商资源中的相对链接的不良影响。（第3.1.4.2节）
To be consistent with the method-neutral parsing algorithm of [RFC7230], the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (Section 4.3.1)
为了与[RFC7230]的方法无关的解析算法保持一致，GET的定义已经放宽，因此请求可以有一个主体，即使主体对GET没有任何意义。（第4.3.1节）
Servers are no longer required to handle all Content-* header fields and use of Content-Range has been explicitly banned in PUT requests. (Section 4.3.4)
服务器不再需要处理所有Content-*头字段，并且在PUT请求中明确禁止使用Content Range。（第4.3.4节）
Definition of the CONNECT method has been moved from [RFC2817] to this specification. (Section 4.3.6)
连接方法的定义已从[RFC2817]移至本规范。（第4.3.6节）
The OPTIONS and TRACE request methods have been defined as being safe. (Section 4.3.7 and Section 4.3.8)
选项和跟踪请求方法被定义为安全的。（第4.3.7节和第4.3.8节）
The Expect header field's extension mechanism has been removed due to widely-deployed broken implementations. (Section 5.1.1)
由于广泛部署的中断实现，Expect header字段的扩展机制已被删除。（第5.1.1节）
The Max-Forwards header field has been restricted to the OPTIONS and TRACE methods; previously, extension methods could have used it as well. (Section 5.1.2)
Max Forwards header字段仅限于选项和跟踪方法；以前，扩展方法也可以使用它。（第5.1.2节）
The "about:blank" URI has been suggested as a value for the Referer header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not sent or has been removed. (Section 5.5.2)
“about:blank”URI被建议在没有引用URI适用时作为Referer头字段的值，这将该情况与未发送或已删除Referer字段的其他情况区分开来。（第5.5.2节）
The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness information present): 204, 404, 405, 414, 501. (Section 6)
以下状态代码现在是可缓存的（也就是说，它们可以在没有显式新鲜度信息的情况下由缓存存储和重用）：204、404、405、414、501。（第6节）
The 201 (Created) status description has been changed to allow for the possibility that more than one resource has been created. (Section 6.3.2)
201（已创建）状态描述已更改，以允许创建多个资源的可能性。（第6.3.2节）
The definition of 203 (Non-Authoritative Information) has been broadened to include cases of payload transformations as well. (Section 6.3.4)
203（非权威信息）的定义已经扩展到包括有效负载转换的情况。（第6.3.4节）
The set of request methods that are safe to automatically redirect is no longer closed; user agents are able to make that determination based upon the request method semantics. The redirect status codes 301, 302, and 307 no longer have normative requirements on response payloads and user interaction. (Section 6.4)
自动重定向安全的请求方法集不再关闭；用户代理能够根据请求方法语义进行确定。重定向状态代码301、302和307不再具有关于响应有效载荷和用户交互的规范性要求。（第6.4节）
The status codes 301 and 302 have been changed to allow user agents to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
状态代码301和302已更改，以允许用户代理将方法从POST重写为GET。（第6.4.2节和第6.4.3节）
The description of the 303 (See Other) status code has been changed to allow it to be cached if explicit freshness information is given, and a specific definition has been added for a 303 response to GET. (Section 6.4.4)
303（请参阅其他）状态代码的描述已更改，以允许在给出显式新鲜度信息的情况下缓存该代码，并为303响应添加了一个特定的定义。（第6.4.4节）
The 305 (Use Proxy) status code has been deprecated due to security concerns regarding in-band configuration of a proxy. (Section 6.4.5)
305（使用代理）状态代码已被弃用，因为存在有关代理带内配置的安全问题。（第6.4.5节）
The 400 (Bad Request) status code has been relaxed so that it isn't limited to syntax errors. (Section 6.5.1)
400（错误请求）状态代码已经放宽，因此它不限于语法错误。（第6.5.1节）
The 426 (Upgrade Required) status code has been incorporated from [RFC2817]. (Section 6.5.15)
426（需要升级）状态代码已并入[RFC2817]。（第6.5.15节）
The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date, rather than all systems sending a date. (Section 7.1.1)
HTTP date和date header字段的需求目标已减少到生成日期的系统，而不是所有发送日期的系统。（第7.1.1节）
The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)
Location header字段的语法已经更改，以允许所有URI引用，包括相对引用和片段，并澄清了何时不适合使用片段。（第7.1.2节）
Allow has been reclassified as a response header field, removing the option to specify it in a PUT request. Requirements relating to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value. (Section 7.4.1)
“允许”已重新分类为响应标头字段，删除了在PUT请求中指定该字段的选项。有关许可证内容的要求已经放宽；相应地，客户不需要总是相信它的价值。（第7.4.1节）
A Method Registry has been defined. (Section 8.1)
已定义方法注册表。（第8.1节）
The Status Code Registry has been redefined by this specification; previously, it was defined in Section 7.1 of [RFC2817]. (Section 8.2)
本规范重新定义了状态代码注册表；在此之前，[RFC2817]第7.1节对其进行了定义。（第8.2节）
Registration of content codings has been changed to require IETF Review. (Section 8.4)
内容编码的注册已更改为需要IETF审查。（第8.4节）
The Content-Disposition header field has been removed since it is now defined by [RFC6266].
内容处置标头字段已删除，因为它现在由[RFC6266]定义。
The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.
Content-MD5标头字段已被删除，因为它的实现与部分响应不一致。
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: 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 US-ASCII character).
根据[RFC5234]附录B.1中的定义，以下核心规则通过引用包括在内：α（字母）、CR（回车）、CRLF（CR LF）、CTL（控件）、数字（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、HTAB（水平制表符）、LF（换行符）、八位字节（任意8位数据序列）、SP（空格）和VCHAR（任何可见的US-ASCII字符）。
The rules below are defined in [RFC7230]:
[RFC7230]中定义了以下规则：
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
comment = <comment, see [RFC7230], Section 3.2.6>
field-name = <comment, see [RFC7230], Section 3.2>
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
comment = <comment, see [RFC7230], Section 3.2.6>
field-name = <comment, see [RFC7230], Section 3.2>
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
在下面收集的ABNF中，列表规则按照[RFC7230]的第1.2节展开。
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
BWS = <BWS, see [RFC7230], Section 3.2.3>
BWS = <BWS, see [RFC7230], Section 3.2.3>
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type
Date = HTTP-date
Date = HTTP-date
Expect = "100-continue"
Expect = "100-continue"
From = mailbox
From = mailbox
GMT = %x47.4D.54 ; GMT
GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date
HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
IMF fixdate=日期名称“，”SP date1 SP时间SP GMT
Location = URI-reference
Location = URI-reference
Max-Forwards = 1*DIGIT
Max-Forwards = 1*DIGIT
OWS = <OWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds
RWS = <RWS, see [RFC7230], Section 3.2.3>
Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) )
Server = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
User-Agent = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
User-Agent = product *( RWS ( product / comment ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) )
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year
charset = token
codings = content-coding / "identity" / "*"
comment = <comment, see [RFC7230], Section 3.2.6>
content-coding = token
charset = token
codings = content-coding / "identity" / "*"
comment = <comment, see [RFC7230], Section 3.2.6>
content-coding = token
date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT
date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT
field-name = <comment, see [RFC7230], Section 3.2>
field-name = <comment, see [RFC7230], Section 3.2>
hour = 2DIGIT
hour = 2DIGIT
language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter )
mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token
minute = 2DIGIT
month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec
media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token
minute = 2DIGIT
month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date
obs-date = rfc850-date / asctime-date
parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
product = token [ "/" product-version ]
product-version = token
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
product = token [ "/" product-version ]
product-version = token
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
rfc850日期=日-name-l，“SP日期2 SP当日时间SP GMT
second = 2DIGIT subtype = token
第二个=2数字子类型=标记
time-of-day = hour ":" minute ":" second
token = <token, see [RFC7230], Section 3.2.6>
type = token
time-of-day = hour ":" minute ":" second
token = <token, see [RFC7230], Section 3.2.6>
type = token
weight = OWS ";" OWS "q=" qvalue
weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT
year = 4DIGIT
Index
指数
1 1xx Informational (status code class) 50
1 1xx信息性（状态代码等级）50
2 2xx Successful (status code class) 51
2 2xx成功（状态代码等级）51
3 3xx Redirection (status code class) 54
3 3xx重定向（状态代码等级）54
4 4xx Client Error (status code class) 58
4个4xx客户端错误（状态代码类）58
5 5xx Server Error (status code class) 62
5 5xx服务器错误（状态代码等级）62
1 100 Continue (status code) 50 100-continue (expect value) 34 101 Switching Protocols (status code) 50
1 100继续（状态代码）50 100继续（期望值）34 101交换协议（状态代码）50
2 200 OK (status code) 51 201 Created (status code) 52 202 Accepted (status code) 52 203 Non-Authoritative Information (status code) 52 204 No Content (status code) 53 205 Reset Content (status code) 53
2 200正常（状态代码）51 201创建（状态代码）52 202接受（状态代码）52 203非权威信息（状态代码）52 204无内容（状态代码）53 205重置内容（状态代码）53
3 300 Multiple Choices (status code) 55 301 Moved Permanently (status code) 56 302 Found (status code) 56 303 See Other (status code) 57 305 Use Proxy (status code) 58 306 (Unused) (status code) 58 307 Temporary Redirect (status code) 58
3 300多项选择（状态代码）55 301永久移动（状态代码）56 302找到（状态代码）56 303参见其他（状态代码）57 305使用代理（状态代码）58 306（未使用）（状态代码）58 307临时重定向（状态代码）58
4 400 Bad Request (status code) 58 402 Payment Required (status code) 59 403 Forbidden (status code) 59 404 Not Found (status code) 59 405 Method Not Allowed (status code) 59 406 Not Acceptable (status code) 59 408 Request Timeout (status code) 60 409 Conflict (status code) 60
4400错误请求（状态代码）58 402要求付款（状态代码）59 403禁止（状态代码）59 404未找到（状态代码）59 405方法不允许（状态代码）59 406不可接受（状态代码）59 408请求超时（状态代码）60 409冲突（状态代码）60
410 Gone (status code) 60 411 Length Required (status code) 61 413 Payload Too Large (status code) 61 414 URI Too Long (status code) 61 415 Unsupported Media Type (status code) 62 417 Expectation Failed (status code) 62 426 Upgrade Required (status code) 62
410消失（状态代码）60 411所需长度（状态代码）61 413有效负载太大（状态代码）61 414 URI太长（状态代码）61 415不受支持的媒体类型（状态代码）62 417预期失败（状态代码）62 426所需升级（状态代码）62
5 500 Internal Server Error (status code) 63 501 Not Implemented (status code) 63 502 Bad Gateway (status code) 63 503 Service Unavailable (status code) 63 504 Gateway Timeout (status code) 63 505 HTTP Version Not Supported (status code) 64
5500内部服务器错误（状态代码）63 501未实现（状态代码）63 502坏网关（状态代码）63 503服务不可用（状态代码）63 504网关超时（状态代码）63 505 HTTP版本不受支持（状态代码）64
A Accept header field 38 Accept-Charset header field 40 Accept-Encoding header field 41 Accept-Language header field 42 Allow header field 72
接受头字段38接受字符集头字段40接受编码头字段41接受语言头字段42允许头字段72
C cacheable 24 compress (content coding) 11 conditional request 36 CONNECT method 30 content coding 11 content negotiation 6 Content-Encoding header field 12 Content-Language header field 13 Content-Location header field 15 Content-Transfer-Encoding header field 89 Content-Type header field 10
C可缓存24压缩（内容编码）11条件请求36连接方法30内容编码11内容协商6内容编码头字段12内容语言头字段13内容位置头字段15内容传输编码头字段89内容类型头字段10
D Date header field 67 deflate (content coding) 11 DELETE method 29
D日期标题字段67放气（内容编码）11删除方法29
E Expect header field 34
E预期标题字段34
F From header field 44
F来自标题字段44
G GET method 24 Grammar Accept 38 Accept-Charset 40 Accept-Encoding 41 accept-ext 38 Accept-Language 42 accept-params 38 Allow 72 asctime-date 66 charset 9 codings 41 content-coding 11 Content-Encoding 12 Content-Language 13 Content-Location 15 Content-Type 10 Date 67 date1 65 day 65 day-name 65 day-name-l 65 delay-seconds 69 Expect 34 From 44 GMT 65 hour 65 HTTP-date 65 IMF-fixdate 65 language-range 42 language-tag 13 Location 68 Max-Forwards 36 media-range 38 media-type 8 method 21 minute 65 month 65 obs-date 66 parameter 8 product 46 product-version 46 qvalue 38 Referer 45 Retry-After 69 rfc850-date 66 second 65
G获取方法24语法接受38接受字符集40接受编码41接受分机38接受语言42接受参数38允许72 asctime日期66字符集9编码41内容编码11内容编码12内容语言13内容位置15内容类型10日期67日期65天65天名称65天名称65延迟秒69预期从44 GMT开始65小时65 HTTP日期65 IMF fixdate 65语言范围42语言标记13位置68最大转发36媒体范围38媒体类型8方法21分钟65个月65 obs日期66参数8产品46产品版本46 qvalue 38 Referer 45在69 rfc850日期后重试66秒65
Server 73 subtype 8 time-of-day 65 type 8 User-Agent 46 Vary 70 weight 38 year 65 gzip (content coding) 11
服务器73子类型8时间65类型8用户代理46变化70重量38岁65 gzip（内容编码）11
H HEAD method 25
H头法25
I idempotent 23
I幂等23
L Location header field 68
L位置标题字段68
M Max-Forwards header field 36 MIME-Version header field 89
最大转发头字段36 MIME版本头字段89
O OPTIONS method 31
O期权方法31
P payload 17 POST method 25 PUT method 26
P有效载荷17后置法25后置法26
R Referer header field 45 representation 7 Retry-After header field 69
R Referer头字段45表示7头字段69后重试
S safe 22 selected representation 7, 71 Server header field 73 Status Codes Classes 1xx Informational 50 2xx Successful 51 3xx Redirection 54 4xx Client Error 58 5xx Server Error 62
S safe 22选定表示7，71服务器标题字段73状态代码类1x信息50 2xx成功51 3xx重定向54 4xx客户端错误58 5xx服务器错误62
T TRACE method 32
T示踪法32
U User-Agent header field 46
U用户代理头字段46
V Vary header field 70
V改变标题字段70
X x-compress (content coding) 11 x-gzip (content coding) 11
X压缩（内容编码）11 X-gzip（内容编码）11
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/