RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Table of Contents

View Repo RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - 图1 RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - 图2 

  1.                                                        PROPOSED STANDARD
  2.                                                             Errata Exist
  3. Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
  4. Request for Comments: 7231                                         Adobe
  5. Obsoletes: 2616                                          J. Reschke, Ed.
  6. Updates: 2817                                                 greenbytes
  7. Category: Standards Track                                      June 2014
  8. ISSN: 2070-1721

摘要 / 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）是一种无状态stateless的应用层协议，适用于分布式、协作式的超文本信息系统。本文档定义了 HTTP/1.1 消息的语义，引申为请求方法request methods、请求头字段request header fields、响应状态码response status codes、响应头字段response header fields，连同消息的有效载荷payload（元数据以及消息体内容）以及内容协商content negotiation的机制。

备忘录状态 / 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.

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.

版权声明 / Copyright Notice

Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

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.

1. 引言 / Introduction

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）消息不是一个请求就是一个响应。服务器监听某个连接的请求，解析parse其接收到的每个消息，解释interpret消息内关于请求目标的语义，最后使用一个或多个响应消息来回应该请求。客户端构建请求消息来传达特定的意图，检查接收到的响应来观察其意图是否得到贯彻执行，并确定如何去解释interpret该结果。本文档依据【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 提供了一种统一的接口来对资源resource（章节 2）进行交互，而不必理会资源的类型、性质或者实现implementation，具体是经由对资源的表示形式representations（章节 3）进行操作和传输来实现的。

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 的语义包含了每个请求方法request method所定义的意图（章节 4）、请求头字段request header fields对这些语义的扩展（章节 5）、状态码status codes的含义（用于指定一种机器可阅读的响应，章节 6）、以及出现在响应头字段response header fields里的其他控制数据和资源元数据的含义（章节 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).

本文档还定义了以下内容：资源的表示形式元数据representation metadata，用于描述打算让接收端怎样解释interpret一个有效载荷payload；可能影响内容选择content selection的请求头字段、统称为“内容协商content negotiation”的各种选择算法（章节 3.4）。

1.1. 一致性和错误处理 / Conformance and Error Handling

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

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

Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

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

1.2. 句法标记 / Syntax Notation

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.

本规范使用了扩展巴科斯范式（ABNF）标记法【RFC5234】，另外，出于定义的紧凑性的考虑，本规范对 ABNF 规则进行了扩展（见【RFC7230】章节 7），允许使用一个 # 操作符（类似于 * 操作符，指代“重复”）来定义一种以逗号分隔的列表。

This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].

本规范使用了术语“字符character”、“字符编码方案character encoding scheme”、“字符集charset”、“协议元素protocol element”，其定义见【RFC6365】。

2. 资源 / Resources

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 请求的目标，被称为“资源resource”。HTTP 并不限制一个资源的性质，它仅仅定义了一个可以用来对资源进行交互的接口。每一个资源都被一个统一资源标识符（URI）Uniform Resource Identifier所标识，见【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]).

当客户端构建construct一个 HTTP/1.1 请求消息的时候，它将某种形式的目标 URItarget URI 包含在消息中，见【RFC7230】章节 5.3。当服务器接收到一个请求的时候，它将重新构建reconstruct出一个实际请求 URIeffective request URI（见【RFC7230】章节 5.5）来定位目标资源target resource。

译注：目标 URI 有四种形式：原始形式origin-form、绝对形式absolute-form、权威形式authority-form、星号形式asterisk-form，详情见【RFC7230】章节 5.3。

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 的设计目标之一是将资源识别resource identification与请求语义相分离，使得请求语义全部归属于请求方法request method（章节 4）以及几个请求修饰头字段request-modifying header fields（章节 5）。如果方法语义与 URI 自身所暗含的语义相冲突，正如章节 4.2.1 所述，优先使用方法语义。

3. 资源的表示形式 / Representations

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

考虑到资源resource可以是任何事物，而 HTTP 所提供的统一接口类似于一个窗口，在窗口的一边我们能够对该事物进行观察；而要想对该事物采取行动的话，只能通过消息沟通来让窗口另一边的某个独立的动作执行者来完成。因此，在沟通过程中，我们需要一种“抽象”来表示represent（代替）该事物的当前状态current state或期望状态desired state。而这种“抽象”被称为资源的表示形式representation【REST】。

译注：术语 "representation" 一词源自一种软件架构风格的术语—— REST（Representational Style Transfer），也就是我们常常听到的 RESTful 风格。资源的表示形式representation是资源resource的抽象，资源一般是唯一的，而资源的表示形式可以多种多样，例如，一份银行流水账单可以认为是一种资源，按媒体类型来分，它的表示形式可以有 JSON、XML 或者二进制格式等，按时间来分，它的表示形式可以有昨日收支、今日收支、本用收支等，更详细的介绍可以查看这里。

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 的目的，资源的表示形式representation是一种信息，该信息用于反映某个给定资源的过去、现在、或将来期望的状态。它以一种能够轻易地经由协议进行传达的格式，并由一系列 元数据representation metadata以及一个可能是无限大的 数据representation data（流）组成。

译注：再强调一次，资源的表示形式representation是资源的一种抽象，反映的是资源的状态，资源一般有多种状态。引用上面提到的银行流水账单的例子，JSON 形式的表示是它的一种状态，它也可以转变为 XML 形式（状态过渡）。每一种状态由一种资源的表示形式来表示，因此，资源与资源的表示形式是一对多的关系。

下文会多次提及到资源的当前表现形式current representation，它反映了资源的当前状态current state，怎么理解呢？还是拿账单的例子，假设有两个接口，一个接口 A 用来获取今天的总支出，另一个接口 B 用来提交支出。

  • 第一次调用接口 A，返回总支出为 50 元，50 元反映了该接口所对应的资源的当前状态；
  • 调用接口 B 提交一条支出 5 元的数据，这时数据库新增了一条记录，资源的状态发生改变；
  • 每二次调用接口 A，返回总支出为 55 元，55 元反映了该接口所对应的资源的当前状态；

另外，资源的当前表现形式current representation也可以同时有多种，可以这样理解：资源的当前状态可以有多种表现形式。例如接口 A 默认返回的是文本类型，但它还有一个参数 filetype 可以让接口调用者指定返回的数据类型，例如 JSON，那么，文本类型和 JSON 类型的总支出信息皆为接口 B 所对应的资源的当前表现形式。

译注：资源的表现形式representation由表现形式的数据representation data和元数据representation metadata组成。资源的表现形式的数据，即资源本身的数据表示；而资源的表现形式的元数据，是用来描述资源的表现形式（或者描述资源的表现形式元数据自身）的，所以叫作“元数据”。

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

源服务器origin server可能被赋予提供或生成多种资源的表示形式representations的能力，每种表示形式旨在反映目标资源target resource的当前状态。在这种情况下，源服务器会使用某些算法（通常会基于内容协商content negotiation）来选定其中一种对于给定请求来说是最适合的表现形式。这个“已选定的表现形式selected representation”是用来为评估条件请求evaluating conditional requests提供数据和元数据，以及为响应给 GET 请求（章节 4.3.1）的 200 (OK) 和 304 (Not Modified) 响应消息构建有效载荷payload。

3.1. 表示形式元数据 / Representation Metadata

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.

与表示形式相关的头字段提供了表示形式的元数据。当一个消息message包含一个有效载荷payload body时，这些头字段描述了如何解释这个封装在有效载荷内的表示形式数据representation data。在一个回应给 HEAD 请求的响应消息里，这些头字段描述了如果相同的请求是一个 GET 请求的话，将会如何解释这个封装在有效载荷内的表示形式数据representation data。

The following header fields convey representation metadata:

以下头字段负责运载表示形式元数据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

3.1.1. 处理表示形式数据 / Processing Representation Data

3.1.1.1. 媒体类型 / Media Type

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.

为了提供开放、可扩展的数据分类data typing和类型协商type negotiation，HTTP 在 Content-Type （章节 3.1.1.5）和 Accept （章节 5.3.2）头字段中使用互联网媒体类型Internet media types【RFC2046】。媒体类型定义了数据的格式及其各种处理模型，即如何根据接收数据的各个场景来处理该数据。 

  1. media-type = type "/" subtype *( OWS ";" OWS parameter )
  2. type       = token
  3. subtype    = token

The type/subtype MAY be followed by parameters in the form of name=value pairs.

type/subtype 后面 可以 跟着键值对 name=value 形式的多个参数。 

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

上面 ABNF 列出的规则里，type、subtype 以及 parameter 的 name 这三个 token（标记）是不区分大小写的。parameter 的 value 不一定区分大小写，取决于 parameter 的 name 的语义。一个 parameter 的出现与否可能会对一个媒体类型的处理有重要意义，取决于该 parameter 在媒体类型登记表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:

如果 parameter 的 value 符合 token 的语法规则的话，那么，它既可以直接作为标记来传输，也可以用在双引号字符串quoted-string里。使用双引号包裹与否都是等价的。例如，以下例子都是等价的，但是为了一致性，应优先使用第一种：

译注：token，标记、记号，编程语言中的变量名、常量名就是 token，token 在 ABNF 中有明确的定义，它的命名不能出现某些特殊字符，详情见【RFC7230】章节 3.2.6。 

  1. text/html;charset=utf-8
  2. text/html;charset=UTF-8
  3. Text/HTML;Charset="utf-8"
  4. text/html; charset="utf-8"

Internet media types ought to be registered with IANA according to the procedures defined in [BCP13].

应该按照【BCP13】所定义的手续，将互联网媒体类型Internet media types登记在 IANA 里。

Note: Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.

注意： 不像其他头字段里的某些类似结构，媒体类型的参数不允许在等号（"="）两边带有空白（即使是 BWS 也不允许）。

3.1.1.2. 字符集 / Charset

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 使用字符集名称charset names来表明或协商一个文本类型的表现形式representation的字符编码方案character encoding scheme【RFC6365】。字符集由一个不区分大小写的标记token来标识。 

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

应该按照定义在【RFC2978】的手续，将字符集名称charset names登记在 IANA 的 "Character Sets" 登记表里。

3.1.1.3. 规范化和文本缺省 / Canonicalization and Text Defaults

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 media types是使用一种规范形式canonical form来登记的，以便于在具有不同本地编码格式的系统之间能够相互操作。经由 HTTP 来选择或传输的资源表示形式representations应该使用规范形式，其原因已经在多用途互联网邮件扩展Multipurpose Internet Mail Extensions（MIME）【RFC2045】里描述过了。然而，电子邮件调度（即存储和转发消息到其他对方）的性能特征跟在 HTTP 和 Web（其于服务器的信息服务）中通用的性能特征有明显的区别。此外，在 MIME 里为了兼容旧的邮件传输协议所设计的约束并不适用于 HTTP（见附录 A）。

译注：canonical form (or normal form, or standard form) 的解释见 wikipedia: Canonical form。

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 来表示一个换行符，只要求所使用的换行符在整个资源表示形式representation中是统一的。HTTP 发送端 可以 在文本类型媒体中生成由 CRLF、或者单纯是 CR、或者单纯是为 LF 组成的换行符。HTTP 接收端 必须 能够解析文本类型媒体中的由 CRLF、或者单纯是 CR、或者单纯是 LF 组成的换行符。而且，在 HTTP 里的文本类型媒体并不限于使用 13 作为 CR，10 作为 LF 的字符集。这种对于换行符的灵活性仅适用于声明为 "text" 媒体类型的表示形式representation以内的文本，它并不适用于 "multipart" 类型，也不适用于有效载荷以外的 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.

如果一种表示形式representation使用了一种内容编码值content-coding来编码，基础数据underlying data应该在编码之前处于上述定义的那种规范形式。

译注："underlying data" 译为基础数据，指的是在编码之前的原始数据。

3.1.1.4. Multipart 类型 / Multipart Types

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 提供了大量的 "multipart" 类型，即在单独一个消息体message body里封装了一个或多个表示形式representations。所有 "multipart" 类型共享一个通用的句法（见【RFC2046】章节 5.1.1），并且包含一个 boundary 参数作为媒体类型的值的一部分。消息体本身就是一个协议元素，发送端 必须 在消息体的各个分部parts之间仅生成 CRLF 来表示换行符。

译注：multipart 允许在一个消息体里包含多个 representation，每个 representation 之间使用 boundary 所指定的定界符来分隔，这样就使得消息体被分割为多个分部，分部与分部之间的内容仍然只能使用 CRLF 作为换行符。multipart 的一个例子可以参考【RFC2049】附录 A。

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 消息分帧message framing 并不会使用 multipart 的 boundary 作为消息体长度的一个标识符，虽然它可能被实现implementations用于生成或处理有效载荷。例如，"multipart/form-data" 类型通常用于在一个请求里携带表单数据，如【RFC2388】所述。"multipart/byteranges" 类型是由本规范所定义的，用在某些 206 (Partial Content) 响应里【RFC7233】。

3.1.1.5. Content-Type

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 头字段指明了它所关联的表示形式representation的媒体类型。所述“关联的表示形式”，是封装在消息有效载荷内的表示形式或者已选表示形式selected representation，由消息语义所决定。 Content-Type 所指定的媒体类型定义了表示形式representation的数据格式以及期望该数据被接收端如何处理，在该消息的语义范围之内，在依照 Content-Encoding 里的所有内容编码进行解码之后。 

  1. 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 头字段的一个例子： 

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

如果发送端所生成的消息包含有一个有效载荷，那么发送端 应当 在该消息里生成一个 Content-Type 头字段，除非它并不知道应该对封装在有效载荷内的表示形式representation指定哪一种媒体类型。如果没有出现 Content-Type 头字段，接收端 可以 要不假定为 "application/octet-stream" 媒体类型（【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.

实际上，资源所有者resource owners并不总是能恰当地配置它们的源服务器来为一个给定的表示形式representation提供正确的 Content-Type，出于这种原因，某些客户端会检查有效载荷的内容然后重写override指定的类型。但是，客户端这样做可能会得出错误的论断，从而可能会暴露出额外的安全风险（例如，特权提升privilege escalation）。而且，通过检查数据格式是不可能确定发送端的真正意图的，这是由于某些数据格式能够匹配多种媒体类型，而仅在语义处理会有所不同。鼓励实现者提供一种方法，当启用这种方法的时候可以禁用上述这种“内容嗅探content sniffing”。

译注：特权提升的详细介绍见 Wikipedia: Privilege escalation 或者 维基百科（中文）。

3.1.2. 为压缩或完整性而编码 / Encoding for Compression or Integrity

3.1.2.1. Content Codings

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 的值指明了一种已经或能够应用到一个表示形式representation的编码转换encoding transformation。content coding 主要用来允许在没有丢失表示形式representation之前的媒体类型的身份以及没有丢失信息的情况下，对该表示形式进行压缩或者进行其他方式的转换。表示形式常常被存储为编码过的形式code form，然后将其直接进行传输，最后仅到达最终接收端才会进行解码。

译文：本译文将 "encoding" 翻译为“编码”，为了与之区分，不会对 "content coding" 进行翻译（实际上是我不知道怎么翻译才好，意会，意会）。 

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

所有 content-coding 的值都是不区分大小写的，并且应该登记到 "HTTP Content Coding Registry" 登记表里，如章节 8.4 所述。它们用在 Accept-Encoding （章节 5.3.4）和 Content-Encoding （章节 3.1.2.2）头字段里。

The following content-coding values are defined by this specification:

本规范定义了以下 content-coding 值：

3.1.2.2. Content-Encoding

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 头字段指明了已经对表示形式representation应用了哪些突破其固有的媒体类型的 content codings，因此得知，为了获得 Content-Type 头字段所提及的那种媒体类型的数据，需要应用哪一种解码机制。Content-Encoding 主要用来允许在没有丢失表示形式representation之前的媒体类型的身份的情况下，对一个表示形式representation的数据进行压缩。 

  1. Content-Encoding = 1#content-coding

An example of its use is

它的用法见下面这个例子： 

  1. Content-Encoding: 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.

如果对一个表示形式representation应用了一种或多种编码，应用这些编码的发送端 必须 生成一个 Content-Encoding 头字段，以它们被应用的先后顺序来一一列出对应的 content codings。如果某种编码需要附带额外的参数信息，可以由其他未在本规范上定义过的头字段来提供。

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.

不像 Transfer-Encoding （【RFC7230】章节 3.3.1），列在 Content-Encoding 头字段上的 codings 是表示形式representation的特性。表示形式representation是依据其编码过的形式来进行定义的。除非在元数据的定义中另有注明，所有与表示形式相关的其他元数据皆为对这种编码过的形式进行描述的。通常，表示形式representation仅在渲染呈现或类似的用途之前才会被解码。

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

如果媒体类型包含有一种固有的编码inherent encoding，例如一种总是以压缩方式来表示的数据格式，那么，这种编码不要在 Content-Encoding 里重申，哪怕它恰巧与其中一个 content codings 的算法一致。这种 content coding 只会在以下这种情况下才需要在 Content-Encoding 列出：出于某些怪异的原因，需要应用该 content coding 两次才能形成正确的表示形式representation。同样，原服务器可能选择将该同样的数据作为多种表示形式multiple representations来发布，其区别仅在于 coding 是作为 Content-Type 的一部分还是作为 Content-Encoding 的一部分 ，这是因为某些用户代理处理各个响应的行为会有所不同（例如，打开一个“另存为…”对话框，而不是自动解缩并渲染内容）。

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.

如果请求消息里的表示形式representation应用了服务器不支持的 content coding，源服务器 可以 以 415 (Unsupported Media Type) 作为响应。

3.1.3. 受众语言 / Audience Language

3.1.3.1. 语言标签 / Language Tags

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】所定义，语言标签language tag标识了一种人类出于交流信息的目的而通过说、写或其他方式来传达的自然语言。计算机语言被明确排除在外。

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 使用了更广义的 language-range 规则（定义在章节 5.3.5），而 Content-Language 使用了 language-tag 规则，其定义如下： 

  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:

一个语言标签language tag是由一个或多个不区分大小写的子标签组成的，每个子标签之间使用连接符（"-"，"%x2D"）分隔。大多数情况下，一个语言标签包含一个标识了某种关联语系的主要语言子标签primary language subtag（例如，"en" 代表英语English），另外还可以选择性地在其后面附加一连串的子标签来优化或缩小语言范围（例如，"en-CA" 代表一种加拿大Canada英语）。语言标签里不允许存在空白。语言标签的几个例子如下： 

  1. fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

See [RFC5646] for further information.

更多信息见【RFC5616】。

3.1.3.2. Content-Language

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 头字段描述了资源表示形式representation的目标受众的（一种或多种）自然语言。需要注意的是，它可能并不等价于用在表示形式representation里的所有语言。 

  1. Content-Language = 1#language-tag

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

语言标签language tag定义在章节 3.1.3.1 里。Content-Language 的主要目的是让用户能够依据自身的首选语言来标识和区分表示形式representation。所以，如果只想将懂丹麦语Danish-literate的人作为内容的目标受众，那么头字段可以这样设置： 

  1. Content-Language: 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.

如果没有指定 Content-Language 头字段，那么就默认内容是面向所有语言受众的。这可能意味着发送端并不认为它自已是面向具体任一种自然语言的，或者发送端并不知道它自己打算使用哪一种语言。

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 列出多种语言，多种语言，例如，一份“怀唐伊条约Treaty of Waitangi”的译文，会同时出现毛利语原文original Maori以及英文版本，那么可以这样设置： 

  1. Content-Language: 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".

然而，只因为在一个表示形式representation里出现了多种语言就认为它是打算面向认识多种语言的受众，这是错误的。举个例子，一本面向新手的语言入门读物，就称为《第一堂拉丁语课》吧，是明确打算面向懂英语的读者的，那么，最恰当的做法是 Content-Language 只包含 "en"。

Content-Language MAY be applied to any media type — it is not limited to textual documents.

Content-Language 可以应用于任意媒体类型media type 的表示形式representation里，也就是说，它并不仅限于文本类的文档textual documents。

3.1.4. 标识 / Identification

3.1.4.1. 标识一种表示形式 / Identifying a Representation

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.

当一个完整的或部分的 representation 被传入到一个消息的有效载荷message payload里，该 representation 所对应的资源标识符通常交由发送端去提供，或者交由接收端去决定会更好一些。

For a request message:

  • 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.
  • Otherwise, the payload is unidentified.

对于一个请求消息来说：

  • 如果 该请求有一个 Content-Location 头字段，意味着发送端断言assert请求消息的有效载荷是某个资源的一个 representation，而该资源是由 Content-Location 的值所标识的。但是，除非这种断言assertion能够通过其他途径（本规则并没有定义有什么途径）来验证，否则不能相信该断言。对于修正历史链接，该信息还是有用的。
  • 否则，该请求消息的有效载荷是未标识unidentified的。

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]).
  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.
  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.
  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).
  5. Otherwise, the payload is unidentified.

对于一个响应消息来说，以下规则会被按顺序应用，直到匹配其中之一：

  • 如果 请求方法是 GET 或者 HEAD，且响应状态码是 200 (OK)、204 (No Content)、206 (Partial Content) 或者 304 (Not Modified)，那么，响应消息的有效载荷是某个资源的 representation，而该资源是由实际请求 URIeffective request URI 所标识的（【RFC7230】章节 5.5）。
  • 如果 请求方法是 GET 或者 HEAD，且响应状态码是 203 (Non-Authoritative Information)，那么，响应消息的有效载荷是某个资源的 可能已被修改过或增强过的 representation，该 representation 由某个中间人提供。
  • 如果 响应带有一个 Content-Location 头字段并且它的字段值是一个跟实际请求 URIeffective request URI 相同的 URI 引用，那么，响应消息的有效载荷是某个资源的 representation，而该资源是由实际请求 URI 所标识的。
  • 如果 响应带有一个 Content-Location 头字段并且它的字段值是一个跟实际请求 URIeffective request URI 不相同的 URI 引用，那么，发送端断言该有效载荷是某个资源的 representation，而该资源是由 Content-Location 的字段值所标识的。但是，除非这种断言assertion能够通过其他途径（本规则并没有定义有什么途径）来验证，否则不能相信该断言。
  • 否则，该响应消息的有效载荷是未标识的。
3.1.4.2. Content-Location

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 可以作为一种标识符来标识与封装在消息的有效载荷内的资源表示形式representation所对应的具体资源。换句话说，如果某个用户代理对这个 URI 执行了 GET 请求，那么会回应一个 200 (OK) 响应消息，该响应消息的有效载荷会封装相同的表示形式representation。 

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

Content-Location 的值并不是用来替换实际请求 URIeffective request URI（【RFC7230】章节 5.5）的。它是一种表示形式元数据representation metadata。它具有与定义在 MIME 的同名头字段（【RFC2557】章节 4）相同的句法和语义。但是，这个头字段出现在一个 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.

如果 Content-Location 被包含在一个 2xx (Successful) 响应消息里，且它的值指向于（在转换为绝对形式absolute form之后）一个与实际请求 URI 相同的 URI，那么，接收端 可以 将该有效载荷认为是对应资源在特定时间里的当前表示形式current representation，所述“特定时间”是指由消息诞生日期message origination date所指定的时间。对于 GET（章节 4.3.1）或者 HEAD（章节 4.3.2）请求来说，这与在服务器没有提供 Content-Location 头字段的情况下的默认语义相一致。对于类似 PUT（章节 4.3.4）或者 POST（章节 4.3.3）这些会改变资源状态state-changing的请求来说，这意味着服务器的响应包含了这个资源的新的表示形式representation，由此与那些只报告动作方面的信息（例如，“它生效了！It worked!”）的表示形式representations作区分。让编辑程序能够在不需要再次发起 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.

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

如果 Content-Location 被包含在一个 2xx (Successful) 响应消息里，且它的字段值指向于一个与实际请求 URI 不相同的 URI，那么，源服务器声称claim该 URI 是一个与封装在该有效载荷内的表示形式representation相对应的不同资源的标识符。这种声称只能在这两个标识符具有相同的资源所有者，且该资源所有者不能经由 HTTP 以编程方式来确定的情况下才能被相信。

  • 对于回应给 GET 或 HEAD 请求的一个响应，它表明：实际请求 URIeffective request URI 指向到一个服从内容协商content negotiation的资源，并且针对已选表示形式selected representation来说，Content-Location 的字段值是一个更加具体的标识符。
  • 对于回应给会改变资源状态的请求方法state-changing method的一个 201 (Created) 响应，如果 Content-Location 的字段值与 Location 的字段值相同，表明：这个有效载荷是新近被创建的资源的当前表示形式current representation。
  • 否则，这个 Content-Location 表明：这个有效载荷是一个对所请求的动作的状态方面进行报告的 representation，且对于给定的 URI ，同样的报告是可供使用的（用于将来 GET 请求对表示形式representation进行访问）。例如，一个经由 POST 请求而产生的购买交易可能包含一个以一份收款凭据作为 200 (OK) 响应的有效载荷，Content-Location 的字段值提供了一个标识符，用于将来重新获取这份收款凭据的一个备份。

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.

用户代理在其发送的请求消息里带有 Content-Location 是想表达它的字段值里的 URI 指的是用户代理最开始是在哪里获得这个封装在有效载荷内的表示形式representation的内容的（在该用户代理对这个表示形式所作的任何更改之前）。也就是说，该用户代理提供了一种的反向链接back link1来指向于原始表示形式original representation的来源source。

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.

源服务器在一个请求消息中接收到 Content-Location 头字段的时候，必须 将该头字段的信息作为暂时的请求上下文transitory request context来对待，而不是作为元数据被逐字保存来成为资源表示形式representation的一部分。源服务器 可以 使用该上下文来指导请求的处理，或者将其保存起来留作其他用途，例如，用于来源链接source links或元数据的版本管理versioning metadata。但是，源服务器 禁止 使用这种上下文信息来改变该请求的语义。

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.

例如，如果一个客户端对一个协商过的资源negotiated resource发起一个 PUT 请求，并且源服务器接受了这个 PUT（没有经过重定向redirection），那么，资源的新状态预期将与提供自该 PUT 请求的表示形式representation相一致；PUT 请求里的 Content-Location 头字段不能当作是一种反向内容选择标识符reverse content selection identifier来仅对协商的表示形式representations中的其中一种进行更新。如果客户端想要后者这种语义，它可以直接对 Content-Location 的 URI 应用 PUT 请求。

3.2. 表示形式数据 / Representation Data

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 消息相关联的表示形式数据representation data是被提供作为消息的有效载荷，或者被消息的语义和实际请求 URI 所引用。表示形式数据representation data是处于某种由表示形式元数据representation metadata相关的头字段所定义的格式和编码之中的。

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:

表示形式数据representation data的数据类型是由 Content-Type 和 Content-Encoding 头字段决定的。它们共同定义了一种双层的、顺序编码的模型two-layer, ordered encoding model： 

  1. representation-data := Content-Encoding( Content-Type( bits ) )

3.3. 有效载荷的语义 / Payload Semantics

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 消息会传输一个完整的complete或者部分的partial资源表示形式representation来作为消息的“有效载荷payload”。在某些情况下，一个有效载荷可能只包含表示形式representation相关的头字段（例如，回应给 HEAD 的响应消息），或者只有表示形式的某（几）部分（例如，206 (Partial Content) 状态码）。

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.

对于请求消息里的有效载荷，其目的是由请求方法的语义request method semantics来定义的。例如，在一个 PUT 请求（章节 4.3.4）的有效载荷内的资源表示形式representation代表如果成功执行该请求以后，目标资源target resource的预期的状态。而一个 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.

在一个响应消息里，有效载荷的目的是由请求方法request method和响应状态码reponse status code两者共同来定义的。例如，一个回应给 GET 请求（章节 4.3.1）的 200 (OK) 响应消息表示在消息诞生日期message origination date（章节 7.1.1.2）所观察到的目标资源target resource的目前状态。而一个回应给 POST 请求的 200 (OK) 响应消息可能表示：或者是在应用该请求以后的处理结果，或者是在应用该请求以后目标资源的新状态。带有一个错误状态码的响应消息通常会包含一个表示该错误条件的有效载荷，以描述错误状态以及如何解决错误的下一步建议。

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.

专门用于描述有效载荷（而不是描述它所关联的表示形式representation）的头字段，被称为“有效载荷头字段payload header fields”。有效载荷头字段被定义在本规范的其他部分中，由它们对消息解析message parsing的影响来决定。

译注：有效载荷头字段并不是说这些头字段在有效载荷里，它们依然被放置在消息头部header section里。

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]

3.4. 内容协商 / Content Negotiation

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.

响应在运载有效载荷信息的时候，无论是表达成功还是失败，源服务器通常会有多种不同的方式来表示该信息，例如，以不同的格式、语言或编码来表示。同样，不同的用户或用户代理可能有不同的能力、特性或者偏好，会影响到源服务器。也就是说，在所有可用的表示形式representations中，究竟响应哪一种表示形式representation才是最合适交付的。出于上述原因，HTTP 提供了内容协商content negotiation的机制。

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 selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in applicability and practicality.

本规范定义了两种内容协商的模式，使之能够在协议里可见：“主动型proactive”和“响应式reactive”。对于主动型内容协商，服务器会依据用户代理申明的偏好来选择 representation。对于响应式内容协商，服务会提供一系列的表示形式representations供用户代理选择。其他的内容协商的模式包括：“条件内容conditional content”，表示形式representation由多个部分组成，源服务器基于用户代理的参数来选择性地渲染各个部分；“活动内容active content”，表示形式representation含有一个脚本，该脚本可以基于用户代理的特性来生成额外的（更加具体的）请求；“透明内容协商Transparent Content Negotiation”（【RFC2295】），由一个中间人来执行内容选择。这些模式不是互斥的mutually exclusive，每种都有其适应性applicability和实用性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 都不知道资源的语义。源服务器响应给请求所遵循的一致性，随着时间和内容协商的不同维度的变化，因而一个资源所观察到的各个表示形式representations随着时间所表现出的“相同性”，是完全取决于实体还是算法，选择还是生成了什么响应。HTTP 并不在意幕后的人物。

3.4.1. 主动型协商 / Proactive Negotiation

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.

用户代理发送包含内容协商的偏好信息的请求到服务器，让服务器的某个算法来选择首选的表示形式preferred representation，称之为主动型协商proactive negotiation（也称服务器驱动型协商server-driven negotiation）。这种选择是基于可供响应使用的表示形式representations（维度有很多，例如语言、内容编码等），对比多种由请求提供的信息，包括显式协商头字段（章节 5.3）和隐式特性两者，例如客户端的网络地址或者 User-Agent 头字段的部分信息。

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.

主动型协商适用于以下情况：当难以向用户代理描述清楚服务器的选择算法（如何从可使用的表现形式available representations 之中选择最佳的一个）；或者当服务器倾向于在发送第一个响应到用户代理的时候就附带上它的“最佳猜测best guess”（希望如果该“最佳猜测”对于该用户来说已经足够好的话，就能够避免后续请求的往返延时round trip delay）。为了提升服务器猜测的准确性，用户代理 可以 在其发送的请求消息中包含某些头字段来描述自身的偏好preferences。

Proactive negotiation has serious disadvantages:

  • 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?);
  • 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;
  • It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
  • It limits the reusability of responses for shared caching.

主动型协商有以下严重的弊端：

  • 对于任何给定的用户，要让服务器精准确定什么才是“最佳表示形式best representation”是不可能的，这是因为这需要全面了解用户代理的功能capabilities及其对响应的使用意图intended use（例如，用户是否想在屏幕上浏览或者将其打印成纸质的？）；
  • 让用户代理在每次请求里都要描述自身的能力是非常低效的inefficient（假定只有一小部分响应带有多个表示形式multiple representations），而且对用户的隐私有潜在风险；
  • 复杂化了源服务器的实现和生成响应给到请求的算法；
  • 限制了共享缓存shared caching的复用性reusability。

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.

用户代理不能信赖主动型协商的预设preferences会一直被遵循，这是因为源服务器可能没有对所请求的资源实现主动型协商，或者认为发送一个并不符合用户代理的偏好的响应比发送一个 406 (Not Acceptable) 响应要好。

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 头字段（章节 7.1.4）通常用来指明主动型协商的选择算法会用到请求信息的哪些部分。

3.4.2. 响应式协商 / Reactive Negotiation

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.

使用响应式协商reactive negotiation（也称代理驱动型协商agent-driven negotiation），选择哪一个作为响应的最佳表示形式best representation（且不论响应状态码response status code）是由用户代理在接收到一个来自源服务器的初始响应initial response之后执行的。这个初始响应会包含备选的表示形式alternative representations的一个列表。如果用户代理不满意初始响应的表示形式，它可以（基于包含在上述列表中的元数据来）选择向一个或多个备选表示形式所对应的 URI 发起 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).

需要注意的是，上述指的是响应的表示形式，通常来说，并不是指资源的表示形式。如果提供那些备选表示形式alternative representations的响应带有如下语义：成为目标资源的一种表示形式（例如，一个回应给 GET 请求的 200 (OK) 响应）；或者提供链接到该目标资源的备选表示形式（例如，一个回应给 GET 请求的 300 (Multiple Choices) 响应），那么，备选表示形式仅考虑目标资源的表示形式。

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.

服务器可能选择不发送一个初始表示形式，而是只发送备选列表list of alternatives，从而表明：它首选由用户代理来执行的响应式协商。例如，列在带有 300 (Multiple Choices) 和 406 (Not Acceptable) 状态码的响应里的备选物alternatives，包含了关于可用的表示形式available representations的信息以便用户或用户代理作出选择。

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.

响应式协商适用于以下情况：当响应会随常用维度（例如类型、语言、编码等）而变化；当源服务器无法通过检测请求而确定用户代理的能力；当使用公共缓存public caches来分发服务器的负载和降低网络使用。

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.

响应式协商存在以下缺点：需要传递备选列表到用户代理，并且需要另一个请求来获得一种备选表示形式。 在消息头部里传递备选列表势必会导致用户观感延时的降级degrades user-perceived latency。而且，本规范并没有定义用于支持自动选择的机制，但它也没有阻止这样一种机制发展成为扩展。

译注：MDN web docs 里对内容协商有更详细的描述。

4. 请求方法 / Request Methods

4.1. 概况 / Overview

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.

请求方法的标记token是请求语义的主要来源，它指明了客户端发起这次请求的目的以及它期望什么作为成功结果。

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）的出现而被进一步深化further specialized，如果这些头字段的语义与方法的语义并不冲突的话。例如，客户端能够发送条件请求头字段conditional request header fields（章节 5.2）以使对目标资源的当前状态的请求动作带有条件conditional（【RFC7232】）。 

  1. 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 最初是被设计为用来作为分布式对象系统distributed object systems的一种接口。请求方法被设想为向某个目标资源应用语义，这就跟在某个被标识的对象上执行某个已定义的方法会应用相应的语义一样。方法标记method tokens是区分大小写的，这是因为它可能用作一种区分方法名称大小写的网关，来对基于对象的系统object-based systems进行访问。

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 里，标准请求方法standardized request methods不是资源特定的resource-specific，这是因为提供统一接口是为了在基于网络的系统中有更好的可见性和复用（【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 字母。

方法 描述 章节
GET 传输目标资源的一种当前表示形式 4.3.1
HEAD 与 GET 相同，除了仅传输状态行和消息头部 4.3.2
POST 对请求有效载荷执行特定资源的处理 4.3.3
PUT 使用请求有效载荷来替换目标资源的所有当前表示形式 4.3.4
DELETE 删除目标资源的所有当前表示形式 4.3.5
CONNECT 与目标资源所标识的服务器建立隧道 4.3.6
OPTIONS 描述关于目标资源的通信选项 4.3.7
TRACE 执行一种沿着目标资源的路径的消息 loop-back 测试 4.3.8

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 维护的 "Hypertext Transfer Protocol (HTTP) Method Registry" 登记表中，其定义见章节 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.

被目标资源target resource所允许的方法集可以列在 Allow 头字段内（章节 7.4.1）。然而，目标资源可以动态改变其允许哪些方法。当源服务器接收到一个不能识别unrecognized或自身未实现的not implemented请求方法时，源服务器 应当 以 501 (Not Implemented) 作为响应。当服务器接收到一个能够识别但目标资源不允许的请求方法时，源服务器 应当 以 405 (Method Not Allowed) 作为响应。

4.2. 公共方法属性 / Common Method Properties

4.2.1. 安全方法 / Safe Methods

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.

如果请求方法所定义的语义本质上是只读read-only的，那么，这种请求方法可以认为是“安全的safe”。例如，在向源服务器的某个目标资源应用某个安全方法safe method以后，客户端既没有请求（要求）not request也没有期望not expect源服务器有任何状态的变化。同样，安全方法的合理使用并不希望对源服务器造成任何损害、财产损失、或者异常负担。

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.

安全方法的这种定义并不妨碍将其实现implement为一种可能包含有害行为的方法，表现为不完全只读，或者当执行某个安全方法时会引起副作用side effects。然而，重要的是，客户端并没有请求（要求）服务器执行额外的行为，并且不能因此而追究客户端的责任。例如，大多数服务器在完成每个响应的时候，会附加上请求信息到访问日志文件里面，而不管这是什么请求方法，这就被认为是安全的，哪怕日志存储可能变满导致服务器崩溃。同样，在网站上发起一个安全的请求来进行广告甄选，通常会有广告账号记账的副作用（即产生广告费用的消耗）。

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.

之所有要区分方法是否安全，是为了可以放心地开启自动检索程序automated retrieval processes（爬虫spider）和缓存性能优化cache performance optimization（预取pre-fetching）而不需要担心引起问题。再者，它让用户代理在处理可能不受信任的内容的时候，能够对非安全方法的自动使用实施适当的约束。

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.

构建一个资源，使在实际请求 URIeffective request URI 里的参数会影响到的请求动作选择，那么，确保该动作是否符合请求方法的语义是资源所有者的责任。例如，基于网站的内容编辑软件Web-based content editing software常常会在查询参数query parameters里使用某些动作，如 "page?do=delete"。如果这种资源的目的是为执行一个非安全的动作unsafe action，那么，当使用一个安全的请求方法safe request method来访问该资源的时候，资源所有者 必须 禁用或者拒绝该动作。否则的话，当自动程序automated processes出于某种目的（为了链接维护，预取，生成搜索索引等）来对每个 URI 执行一个 GET 的时候，会导致不好的副作用。

译注：请求方法是否是安全的，其关注点在于该方法是否有改变资源的状态，而不是平常我们认为的安全性或保密性的概念。只要执行该请求方法后，资源的状态没有被改变，那么这个请求方法就是安全的（哪怕可能会导致数据泄漏、黑客入侵、硬件爆炸等），否则就是不安全的。换句话说，安全的请求方法都是“只读”的，并不会对资源造成任何“写入”，类似于编程语言中 Getter 的概念。

4.2.2. 幂等方法 / Idempotent Methods

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.

当执行多次相同的请求，与单次这样的请求，对服务器的预期效果是一样的，那么，该请求方法被认为是“幂等的idempotent”。本规范所定义的请求方法中，幂等方法有：PUT、DELETE 以及所有安全请求方法。

译注：也就是说，幂等的方法共有GET、HEAD、PUT、DELETE、OPTIONS 和 TRACE。

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.

跟安全的定义类似，请求方法的幂等性只适用于用户究竟请求到了什么，而服务器可以自由地单独记录每个请求的日志，保持一份版本管理历史，或者为每个幂等请求实现其他非幂等的副作用等等。

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.

之所以要区分请求方法的幂等与否，是因为如果在客户端能够读取服务器的响应之前发生了通信失败，请求可以被自动重复发送（见【RFC7230】6.3.1）。例如，如果客户端发送一个 PUT 请求，同时，之前建立好的连接在客户端接收到任何响应之前就被关闭了，那么，客户端可以建立一个新的连接并重试该幂等请求。客户端知道重复该请求会有相同的预期效果，即使原来的请求已经成功了。

4.2.3. 可缓存方法 / Cacheable Methods

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.

请求方法可以被定义为“可缓存的cacheable”来指明：回应给它们的响应能够被保存起来，用于将来的复用，更具体的要求见【RFC7234】。通常，不依赖某个当前响应current response或权威响应authoritative response的安全方法，就是可缓存的cacheable方法。本规范定义了 GET、HEAD 和 POST 作为可缓存的方法，虽然绝大多数的缓存实现cache implementations仅仅支持 GET 和 HEAD。

4.3. 方法的定义 / Method Definitions

4.3.1. GET

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 方法请求获得目标资源的一种当前选定的表示形式current selected representation。GET 是信息获取的主要途径，同时，它也是几乎所有性能优化performance optimizations的重点。因此，当人们谈及经由 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 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.

我们很容易想到将资源标识resource identifiers符作为远程文件系统的路径名称，以及将表示形式representations作为这些远程文件的内容的一种拷贝。事件上，这也是许多资源的实现方式（安全相关注意事项见章节 9.1）。然而，实际上资源并没有被限制为只有这一种实现方式。资源的 HTTP 接口也有可能被实现为一种内容对象树content object tree2、一种基于各种数据库记录的可编程视图、一种到其他信息系统的网关等等。甚至当 URI 的映射机制被捆绑到一种文件系统上，也可以将源服务器配置为将文件连同请求一起作为执行的输入，而输出结果则作为表示形式representation并发送给请求，而不是直接传输文件本身。无论如何，只有源服务器需要了解它的每个资源标识符如何对应到某种实现上，以及每种实现如何在回应到 GET 的响应里达成选择和发送目标资源的某种当前表示形式current representation。

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

客户端能够将 GET 的语义改变为一种“范围请求range request”，通过在其发送的请求消息中带有一个 Range 头字段，来实现只对已选表示形式selected representation中的某（几）部分进行请求传输（【RFC7233】）。

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 请求里带有一个有效载荷可能会导致某些现有的实现implementations拒绝该请求。

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 请求的响应是可缓存的cacheable，缓存cache 可以 使用它来满足随后的 GET 和 HEAD 请求，除非 Cache-Control 头字段另有指定（【RFC7234】章节 5.2）。

译注：来自 MDN 的总结： The HTTP GET method requests a representation of the specified resource. Requests using GET should only retrieve data.

Request has body
No
Successful response has body
Yes
Safe
Yes
Idempotent
Yes
Cacheable
Yes
Allowed in HTML forms
Yes

4.3.2. HEAD

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 方法等价，除了服务器 禁止 在回应 HEAD 请求的响应消息里带有消息体message body（也就是说，响应消息在消息头部header section之后就结束了）。服务器回应给 GET 请求的响应消息里带有什么头字段，回应给 HEAD 请求的响应消息里就 应当 带有什么头字段，除了有效载荷头字段payload header fields（章节 3.3） 可以 被忽略以外。HEAD 方法能够用于在不需要传输表示形式数据representation data的情况下获取已选表示形式selected representation（章节 3） 相关的元数据。同时，它也常用于测试超链接hypertext links的正确性、可访问性和最近是否有修改。

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 请求消息里的有效载荷是没有定义任何语义的，如果在 HEAD 请求里带有一个有效载荷可能会导致某些现有的实现implementations拒绝该请求。

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

回应给 HEAD 请求的响应是可缓存的cacheable，缓存cache 可以 使用它来满足随后的 HEAD 请求，除非 Cache-Control 头字段另有指定（【RFC7234】章节 5.2）。HEAD 响应还可能影响到之前已缓存的 GET 响应，见【RFC7234】章节 4.3.5。

译注：来自 MDN 的总结：

Request has body
No
Successful response has body
No
Safe
Yes
Idempotent
Yes
Cacheable
Yes
Allowed in HTML forms
No

4.3.3. POST

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):

  • Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
  • Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
  • Creating a new resource that has yet to be identified by the origin server; and
  • Appending data to a resource's existing representation(s).

POST 方法请求目标资源按照资源自身的具体语义来处理封装在请求消息里的表示形式representation。例如，POST 是用于以下（或其他）功能。

  • 为某个数据处理进程提供数据块a block of data，例如某个 HTML 表单的域；
  • 发表一个消息到某个电子公告栏、新闻组、邮件列表、博客或者类似的文章组里；
  • 创建一种还没有被源服务器所标识的新的资源；以及
  • 附加数据到某个资源的现有表示形式representation(s)中。

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 (Partial Content)、304 (Not Modified) 以及 416 (Range Not Satisfiable) 是例外。

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 (Created) 响应，且该响应需带有一个 Location 头字段来提供一种标识符，来对应被创建的主要资源（章节 7.1.2）；以及需要包含一种表示形式representation，来描述当引用新资源的时候请求的状态。

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 请求的响应，仅当它们包含明确的新鲜信息freshness information时，才是可缓存的cacheable（见【RFC7234】章节 4.2.1）。然而，对 POST 响应的缓存并没有被广泛实现。如果源服务器希望客户端以一种之后的 GET 能够复用的方式使客户端能够缓存 POST 的结果，面对这种情况，源服务器 可以 发送一个 200 (OK) 响应来包含该结果，并且，该响应还需带有与该 POST 的实际请求 URI 相同的值的一个 Content-Location 头字段（章节 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 请求的结果等价于某个现有资源的某种表示形式representation的话，源服务器 可以 发送一个 303 (See Other) 响应到用户代理，同时，响应里带有 Location 头字段，其值为该现有资源的标识符，让用户代理进行重定向。这样做的好处是可以向用户代理提供一种资源标识符，以及可以通过一种更适合缓存共享的方法来传输表示形式representation，但坏处是可能需要一个额外的请求，如果用户代理还没有缓存过该表示形式representation的话。

译注：来自 MDN 的总结：

The HTTP POST method sends data to the server. The type of the body of the request is indicated by the Content-Type header.

Request has body
Yes
Successful response has body
Yes
Safe
No
Idempotent
No
Cacheable
Only if freshness information is included
Allowed in HTML forms
Yes

4.3.4. PUT

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

PUT 方法请求源服务器使用封装在请求消息有效载荷内的表示形式representation所定义的状态，来新建create或替换replace目标资源的状态。如果向目标资源成功 PUTsuccessful PUT request 了一个给定的表示形式representation，那么我们可以认为，对相同目标资源的后续 GET 请求将会被回应一个 200 (OK) 响应，同时响应会携带一个（与之前 PUT 的表示形式）等价的表示形式。然而，不能保证这种状态的改变能够被客户端所观察到，这是因为在源服务器接收到任何来自该客户端的后续的 GET 请求之前，目标资源就可能被按照其他用户代理并行地执行动作，也有可能受到源服务器的动态处理。对 PUT 请求的成功响应successful response，仅仅意味着在源服务器处理该请求的时候，用户代理达成了它的意图。

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.

如果目标资源并没有当前表示形式current representation，并且 PUT 成功地创建了一种表示形式，那么，源服务器 必须 回应一个 201 (Created) 响应来告知用户代理。如果目标资源已有一种当前表示形式current representation，并且该表示形式的状态被封装在 PUT 请求内的表示形式成功地更改了，那么，源服务器 必须 回应一个 200 (OK) 或者一个 204 (No Content) 来指明请求已经成功完成了。

译注：由此可见，PUT 会改变 representation 的状态，因此，它不是一个安全方法safe method。而 PUT 是一个幂等方法idempotent method，由上述可知，多次相同的 PUT 请求与一次 PUT 请求对表示形式representation的影响是一样的。试想一下，一个 PUT 请求，试图将用户 A 的年龄值更新为 18，无论发送一次还是多次这样的请求，用户 A 的年龄值最终依然是 18。

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 请求的未识别的头字段unrecognized header fields（也就是说，不要保存它们作为资源状态的一部分）。

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 的表示形式representation是否符合服务器对目标资源的任何约束constraints，确保它们不能或不会被 PUT 所改变。当源服务器使用与 URI 相关联的内部配置信息来对回应给 GET 的响应的表示形式representation的元数据设置值的时候，这种校验是非常重要的。当一个 PUT 请求内的表示形式不符合目标资源target resource的约束时，源服务器 应当 要不转换transform这个表示形式或者改变资源的配置以使其符合约束条件；要不回应一种恰当的错误消息，包含足够的信息来解释为什么该表示形式并不合适。建议使用 409 (Conflict) 或者 415 (Unsupported Media Type) 状态码，而对于后者（415 (Unsupported Media Type)），带有 Content-Type 头字段以指定具体的约束类型。

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:

  • reconfigure the target resource to reflect the new media type;
  • transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; or,
  • 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.

例如，如果目标资源被配置为总是带有一个 "text/html" 的 Content-Type，并且 PUT 请求内的表示形式representation带有一个 "image/jpeg" 的 Content-Type，那么，源服务器的行为应该是以下其中之一：

  • 将目标资源重新配置以体现该种新的媒体类型；
  • 在保存 PUT 请求的表示形式representation作为目标资源的新状态之前，先将其转换transform为一种符合资源约束的格式；或者
  • 回应一个 415 (Unsupported Media Type) 响应来拒绝该请求并指明目标资源被限定为 "text/html"，响应内可能还包含一条链接link，该链接指向到其他可能适用于该请求目标的资源。

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 并没有定义资源resource究竟是什么，在任何意义上，这超出了由 HTTP 所提供的接口所能表达的。HTTP 并没有定义资源的状态resource state是被如何“存储stored”的，也没有定义资源状态上的改变会导致这种存储如何改变，也没有定义源服务器是如何将资源的状态翻译translate成资源的表示representations的。一般而言，在资源接口后面的所有实现细节都被服务器有意地隐藏起来。

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 的成功响应successful response里带有任何验证器头字段validator header field（章节 7.2），例如 ETag 或者 Last-Modified 头字段，除非请求的表示形式数据representation data是保存在没有经过任何编码转换transformation的消息体（有效载荷）里（也就是说，响应内的新的表示形式数据representation data是等价于接收自 PUT 请求内的表示形式数据representation data），并且该验证器头字段反映的是新的表示形式。上述这种要求让用户代理能够知道这个在自己内存中的表示形式在什么时间内可以保持最新（保持为 current 状态）remain current，由此知道其是否仍然可以继续作为 PUT 请求的结果而不需要从源服务器上再次获取，以及在响应内接收到的新验证器能够被用于将来的条件请求conditional requests以避免新意外覆盖accidental overwrite（章节 5.2）。

译注：未经过任何编码转换的消息体message body等价于有效载荷体payload body，见【RFC7230】章节 3.3.1。

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 两者的根本区别在于它们对封装的表示形式representation的不同意图。POST 所请求目标资源是意图依据该资源自身的语义来处置handle请求内的表示形式。而在 PUT 请求内的表示形式是定义为替换目标资源的状态的。因此，PUT 的意图是幂等的idempotent且对中间人intermediaries是可见的visible，虽然只有源服务器了解其确切的作用。

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 请求的合理解释proper interpretation是相信用户代理是知道哪个目标才是它所期望的。一种为客户端选择恰当的 URI 的服务，在接收到一种会引起状态变化的请求state-changing request以后，应当 被实现为使用 POST 方法而不是 PUT 方法。如果源服务器不将 PUT 所请求的状态改变到目标资源上，而是希望将其应用到另外一个不同的资源上，例如当资源被迁移到另一个不同的 URI 上了，那么，源服务器 必须 回应一个恰当的 3xx (Redirection) 响应给用户代理，然后，用户代理 可以 自行决定是否对请求进行重定向redirect。

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

应用到目标资源target resource的 PUT 请求可能会对其他资源带来副作用side effects。例如，一篇文章可能会有一个用于标识“当前版本the current version”（是一种资源）的 URI，独立于其他每一个标识特定版本的 URIs，不同的资源在某处共享同一种状态来作为“当前版本”所对应的资源。成功地向“当前版本”这个 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 请求包含有一个 Content-Range 头字段（【RFC7233】章节 4.2），源服务器 必须 向该请求回应一个 400 (Bad Request) 响应，这是因为该请求的有效载荷payload很有可能只是部分内容partial content而被错误地当作一个完整的 representation。部分内容的更新partial content updates很可能是通过使用大型资源larger resource的一部分相重叠的状态来定位一个单独标识的资源，或者通过使用另外一种被定义为专门用于部分更新partial updates的方法（例如，定义于【RFC5789】里的 PATCH 方法）。

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 方法的响应是不可缓存的not cacheable。如果一个成功的 PUT 请求successful PUT request穿过一个缓存cache，而该缓存已经存储（缓存）了该 PUT 请求的实际请求 URI 所对应的一个或多个响应（也就是说，缓存命中了这个 PUT 请求），那么这些已存储的（已缓存的）响应将会被失效be invalidated（见【RFC7234】章节 4.4）。

译注：来自 MDN 的总结：

The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload.

The difference between PUT and POST is that PUT is idempotent: calling it once or several times successively has the same effect (that is no side effect), where successive identical POST may have additional effects, like passing an order several times.

Request has body
Yes
Successful response has body
No
Safe
No
Idempotent
Yes
Cacheable
No
Allowed in HTML forms
No

4.3.5. DELETE

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 方法请求源服务器移除目标资源target resource与它当前的功能current functionality之间的关联。实际上，该方法与 UNIX 中的 rm 命令非常类似，DELETE 表达了一种作用在映射到源服务器的 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.

如果目标资源有一个或多个当前表示形式current representations，它们可能会也可能不会被源服务器所销毁，另外，它们所关联的存储可能会也可能不会被回收，这完全取决于资源的性质以及服务器对资源的实现implementation（已经超出了本规范的范畴）。同样，还可能需要去失效deactivate或归档archive资源实现的其他方面，来作为一个 DELETE 操作的结果，比如数据库或者网关连接。总之，我们假设源服务器只会允许对这些资源进行 DELETE：具有某种规定机制来完成删除操作的资源。

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

相对较少的资源会允许 DELETE 方法，它主要应用在用户会有某些关于它的影响效果的指导的远程编辑环境remote authoring environments中。例如，在以前使用一个 PUT 请求来创建好的某个资源，或者是在回应给 POST 请求的一个 201 (Created) 响应以后，该响应里的 Location 头字段所标识的某个资源，可能会允许使用一个对应的 DELETE 请求来撤消undo这些动作。类似的，实现某种编辑方法authoring function的定制的用户代理实现custom user agent implementations，比如使用 HTTP 来进行远程操作的版本管理客户端revision control clients，可能会基于“服务器的 URI 空间URI space是经过精心设计来对应某个版本仓库”的这种假设来使用 DELETE。

译注：URI space 参考【RFC5785】Defining Well-Known Uniform Resource Identifiers (URIs)

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.

如果成功执行了一次 DELETE 方法，如果该动作可能会成功但确定的结果还未出现enacted，源服务器 应当 回应一个 202 (Accepted) 响应；如果该动作的结果已经出现了并且服务器不会再提供更多的信息，应当 回应一个 204 (No Content) 响应；或者如果该动作的结果已经出现了并且响应会包含一个表示形式representation来描述资源的状态，该响应的状态码 应当 是 200 (OK) 。

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.

在 DELETE 请求里的有效载荷payload并没有定义任何的语义，如果在 DELETE 请求里带有一个有效载荷可能会导致某些现有的实现implementations拒绝该请求。

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 方法的响应是不可缓存的not cacheable。如果一个 DELETE 请求穿过一个缓存cache，而该缓存已经存储（缓存）了该 DELETE 请求的实际请求 URI 所对应的一个或多个响应（也就是说，缓存命中了这个 DELETE 请求），那么这些已存储的（已缓存的）响应将会被失效be invalidated（见【RFC7234】章节 4.4）。

译注：来自 MDN 的总结：

The HTTP DELETE request method deletes the specified resource.

Request has body
May
Successful response has body
May
Safe
No
Idempotent
Yes
Cacheable
No
Allowed in HTML forms
No

4.3.6. CONNECT

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 方法请求让对方（接收端）与请求目标request-target所标识的源服务器建立establish一个隧道tunnel，并且如果建立成功以后，将接收端的行为限制为双向盲目转发blind forwarding数据包，直到隧道被关闭为止。隧道常常用于创建一种穿越一个或多个代理proxies的端到端end-to-end的虚拟连接virtual connection，然后能够安全使用 TLS（Transport Layer Security，【RFC5246】）。

译注：需要注意的是，并不是 CONNECT 请求的发送端与源服务器建立隧道，而是 CONNECT 接收端与源服务器建立隧道，这个要清楚。

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 只能用在向代理发送的请求里。源服务器接收到一个发送给它自己的 CONNECT 请求时，可以 回应一个 2xx (Successful) 状态码来表明：连接已被建立好。但是，大多数源服务器并没有实现implement CONNECT。

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,

发送 CONNECT 请求的客户端 必须 以 authority-form（权威形式）的形式来发送请求目标request-target（【RFC7230】章节 5.3），也就是说，请求目标仅由隧道终点的主机名称host name以及端口号port number组成，以冒号分隔。例如： 

  1. CONNECT server.example.com:80 HTTP/1.1
  2. Host: server.example.com:80
  3.  

译注：上例是有一个空行blank line的，表示消息头部header section结束，消息结构的更多详情见【RFC7230】章节 3。

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

作为接收端的代理proxy能够通过以下方式建立一个隧道：直接连接到请求目标；或者，如果该代理被配置为使用另一个代理的话，转发该 CONNECT 请求到下一个入站代理inbound proxy。任何 2xx (Successful) 响应都表明：发送端（以及所有入站代理）将会在成功响应的消息头部header section末尾的空行（该空行表示消息头部结束）以后，马上切换为隧道模式tunnel mode，而在这个空行之后所接收到的数据，是来自由请求目标request target所标识的源服务器的。其他任何不是表示成功的响应则表明这个隧道还没有形成，该连接仍然受到 HTTP 支配（而不是由隧道所扩展的协议来支配，例如 TLS）。

这里涉及到 HTTP 的消息结构和参与的多种角色，如果对这些概念还不够熟悉的话，请先浏览【RFC7230】里的章节 2 和 3。

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.

当隧道中间人tunnel intermediary检测到隧道两端都已关闭了连接的时候，隧道被关闭。中间人 必须 尝试发送所有未偿付的数据outstanding data，从被关闭的一端发送到另一端，然后关闭两端的连接，最后丢弃掉任何还未交付的undelivered的数据。

Proxy authentication might be used to establish the authority to create a tunnel. For example,

代理认证proxy authentication可能被用来确立权威establish authority来创建一个隧道，例如： 

  1. CONNECT server.example.com:80 HTTP/1.1
  2. Host: server.example.com:80
  3. Proxy-Authorization: basic aGVsbG86d29ybGQ=
  4.  

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.

向任意的服务器建立隧道会有严重的风险，特别是当隧道的终点是一个不作为网站流量Web traffic的 TCP 知名端口well-known port或者保留端口reserved port的时候。例如，请求目标为 "example.com:25" 的 CONNECT 请求会建议代理连接到用于 SMTP 流量的保留端口上，如果允许这样做，就会欺骗代理去中转relaying垃圾邮件。因此，支持 CONNECT 的代理 应当 将 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.

服务器 禁止 在一个回应给 CONNECT 的 2xx (Successful) 响应中带有任何 Transfer-Encoding 或者 Content-Length 头字段。客户端 必须 在其接收到的回应给 CONNECT 的成功响应里，忽略掉任何 Content-Length 或者 Transfer-Encoding 头字段。

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.

在 CONNECT 请求消息里的有效载荷是没有定义任何语义的，如果在 CONNECT 请求里带有一个有效载荷可能会导致某些现有的实现implementations拒绝该请求。

Responses to the CONNECT method are not cacheable.

回应给 CONNECT 方法的响应是不可缓存的not cacheable。

译注：来自 MDN 的总结：

The HTTP CONNECT method method starts two-way communications with the requested resource. It can be used to open a tunnel.

For example, the CONNECT method can be used to access websites that use SSL (HTTPS). The client asks an HTTP Proxy server to tunnel the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client.

CONNECT is a hop-by-hop method.

Request has body
No
Successful response has body
Yes
Safe
No
Idempotent
No
Cacheable
No
Allowed in HTML forms
No

4.3.7. OPTIONS

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 方法请求获得可用于目标资源的通信选项communication 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).

如果要向服务器执行 OPTIONS 请求，一般是使用一个星号（""），而不是一个具体的资源，来作为请求目标（【RFC7230】章节 5.3）。这是因为服务器的通信选项一般依赖于资源，"" 请求仅作为方法的一种 "ping" 或者“空操作” 时才有用处，除了让客户端可以去测试服务器的功能以外，它并没有做任何其他事情。例如，用它来测试一个代理是否遵循 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.

如果请求目标不是使用星号形式asterisk-form，那么，OPTIONS 请求所应用到的选项是可用在与目标资源通信的。

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.

服务器在向 OPTIONS 生成一个成功响应的时候，应当 带有所有可能指明以下信息的头字段：由服务器所实现的可选功能，并且这些可选功能是可作用于目标资源的（例如，Allow）。这些头字段还应当包括那些未定义在本规范里的扩展头字段，如果有的话。如果响应里包含有效载荷，那么还可能描述了机器的通信选项，或者供人类阅读的表示形式representation的通信选项。对于这样一种表示形式，本规范并没有定义一种标准格式，但可能会在将来的 HTTP 扩展中进行定义。服务器 禁止 生成带有一个 "0" 值的 Content-Length 头字段，如果该响应没有包含有效载荷的话。

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.

客户端 可以 在一个 OPTIONS 请求中带有一个 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.

客户端生成一个 OPTIONS 请求的时候，如果该请求包含一个有效载荷，那么，该请求 必须 带有一个有效的 Content-Type 头字段来描述表示形式representation的媒体类型。虽然本规范并没有对这样一种有效载荷的用途进行过任何定义，但将来的 HTTP 扩展中可能会使用 OPTIONS 请求的消息体来携带目标资源有关的更细致的查询信息。

Responses to the OPTIONS method are not cacheable.

回应给 OPTIONS 方法的响应是不可缓存的not cacheable。

译注：来自 MDN 的总结：

The HTTP OPTIONS method is used to describe the communication options for the target resource. The client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server.

Request has body
No
Successful response has body
Yes
Safe
Yes
Idempotent
Yes
Cacheable
No
Allowed in HTML forms
No

4.3.8. TRACE

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 方法请求一个远程的、应用层的请求消息回路loop-back。请求链路中的最终接收端final recipient 应当 原样反映reflect它所接收到的消息，排除掉下文所述的那些头字段，作为一个带有值为 "message/http"（【RFC7230】章节 8.3.1）的 Content-Type 的 200 (OK) 响应的消息体，最后返回给客户端。最终接收端指的是源服务器，或者是在请求链路中第一个接收到 Max-Forwards 值为 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.

客户端 禁止 在一个 TRACE 请求里生成以下这种头字段：包含有敏感数据sensitive data的，并且这些敏感数据有可能会被响应暴露disclosed出来的。例如，用户代理在一个 TRACE 请求里包含有存放在本地的用户证书user credentials【RFC7235】或者 cookies【RFC6265】，这种做法是非常愚蠢的。请求的最终接收端final recipient在生成响应正文的时候，应当 排除掉任何有可能包含敏感数据的请求头字段。

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.

TRACE 让客户端能够观察到请求链路的另一端将会接收到什么数据，并且让客户端可以使用这些数据来测试或者诊断信息。在这些数据之中，Via 头字段（【RFC7230】章节 5.7.1）的值是特别让人感兴趣的数据之一，这是因为它记录了请求链路的轨迹。使用 Max-Forwards 头字段可以让客户端对请求链路的长度进行限制，这对测试一条代理链路是否在无限循环转发消息是非常有用的。

A client MUST NOT send a message body in a TRACE request.

客户端 禁止 在一个 TRACE 请求里带有一个消息体。

Responses to the TRACE method are not cacheable.

回应给 TRACE 方法的响应是不可缓存的not cacheable。

译注：来自 MDN 的总结：

The HTTP TRACE method performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism.

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. The final recipient is either the origin server or the first server to receive a Max-Forwards value of 0 in the request.

Request has body
No
Successful response has body
No
Safe
No
Idempotent
Yes
Cacheable
No
Allowed in HTML forms
No

5. 请求头字段 / Request Header Fields

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.

客户端发送请求头字段request header fields来提供更多关于请求上下文的信息，基于目标资源的状态来使请求带有条件conditional，提议响应的首选格式preferred formats，提供认证凭证，或者更改预期的请求处理。这些头字段充当请求的修饰符modifiers，类似于一门编程语言中参与函数调用的参数一样。

5.1. 控制 / Controls

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]

5.1.1. Expect

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 头字段指明了一个确定的行为behaviors（期望expectations）集合，这些期望需要通过服务器的支持来实现，以使得这个请求得以妥善处理。100-continue 是仅有的由本规范所定义的期望。 

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

如果服务器接收到一个带有 Expect 头字段的请求，但其字段值并不是 100-continue，那么，服务器 可以 回应一个 417 (Expectation Failed) 状态的响应来指明不能遇到意料之外的期望unexpected expectation（也就是说，服务器仅能处理 100-continue 这种期望）。

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) 的过渡响应interim response，让客户端在真正要发送这个消息体之前，可以等待服务器的指示来确认是否有必要发送这个消息体。当消息体的体积巨大，或者客户端预见到可能出现错误（例如，当首次发送一个会改变资源状态的请求方法state-changing method的时候没有预先校验认证凭证）的时候，这样做可以提高效率。

译注：过渡响应interim response是相对于最终响应final response来说的。过渡响应即所有 1xx 状态码的响应，所有非 1xx 状态码的响应都是最终响应。

For example, a request that begins with

例如，请求消息的起始内容如下： 

  1. PUT /somewhere/fun HTTP/1.1
  2. Host: origin.example.com
  3. Content-Type: video/h264
  4. Content-Length: 1234567890987
  5. Expect: 100-continue
  6.  

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 (Unauthorized) 或者 405 (Method Not Allowed)。

Requirements for clients:

  • A client MUST NOT generate a 100-continue expectation in a request that does not include a message body.
  • 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.
  • 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.
  • 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).

对于客户端的要求：

  • 客户端 禁止 在一个没有消息体message body的请求里生成一个 100-continue 期望。
  • 客户端在发送请求的消息体之前，如果打算等待服务器的 100 (Continue)，必须 发送一个包含 100-continue 期望的 Expect 头字段。
  • 客户端在发送了一个 100-continue 期望以后，并不要求去等待任意具体的时长。这时候客户端甚至 可以 在未接收到任何响应的情况下就开始发送消息体。再者，由于 100 (Continue) 响应不能经由一个 HTTP/1.0 中间人来转发，因此，这种情况下的客户端 不应当 在发送消息体之前无限期地等待。
  • 客户端接收到一个 417 (Expectation Failed) 状态码的响应，该响应是回应给一个包含 100-continue 期望的请求的，这时候，客户端 应当 再次发起这个请求，但这次请求不会再带有 100-continue 期望，这是因为这个 417 响应只不过是表明：该响应链路response chain并不支持期望（比如，它经过一个 HTTP/1.0 服务器）。

译注：HTTP/1.0 并没有定义任何 1xx 的状态码，所以不支持在 HTTP/1.0 上使用 100-continue。

Requirements for servers:

  • A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
  • 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.
  • 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.
  • 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]).

对于服务器的要求：

  • 当服务器接收到一个 HTTP/1.0 的请求，并且该请求包含一个 100-continue 期望的时候，服务器 必须 忽略掉这个期望。
  • 如果服务器已经接收到部分或全部消息体；或者消息分帧表明这个请求并没有消息体，那么，服务器 可以 省略发送一个 100 (Continue) 响应到对应的请求上。
  • 服务器发送了一个 100 (Continue) 响应，一旦接收到并处理完消息体以后，必须 发送一个最终状态码final status code，除非连接被过早地关闭了。
  • 如果服务器在读取完整个消息体之前就响应了一个最终状态码，那么，服务器 应当 在该响应里表明：它是打算关闭这个连接呢，还是继续读取和丢弃这个请求消息（见【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（或更新的）请求行request-line，以及包含有一个 100-continue 期望并表明随后将会有一个请求消息体到来的完整的消息头部header section，来决定：是立即发送一个带有最终状态码的响应呢，如果该状态仅仅通过检测请求行和头字段就可以确定到的话；还是立即发送一个 100 (Continue) 响应来促使encourage客户端去发送该请求的消息体呢？源服务器在发送 100 (Continue) 响应之前 禁止 等待消息体。

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 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.1（或更新的）请求行request-line，以及包含有一个 100-continue 期望并表明随后将会有一个请求消息体到来的完整的消息头部header section，来决定：是立即发送一个带有最终状态码的响应呢，如果该状态仅仅通过检测请求行和头字段就可以确定到的话；还是开始通过发送一个对应的请求行和消息头部到下一个入站服务器inbound server，来沿着源服务器的方向转发这个请求呢？如果这个代理（依据本地配置或者过去的交互）相信下一个入站服务器仅支持 HTTP/1.0 的话，这个代理 可以 立即生成一个 100 (Continue) 响应来促使客户端开始发送该请求的消息体。

译注：入站、出站的概念见【RFC7230】章节 2.3。

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 头字段早在 HTTP/1.1 规范的第一版【RFC2068】时就已经被引入，当时它是有两个作用的：一是用于请求一个 100 (Continue) 过渡响应，二是作为一种通用机制来表明：这是一种“必须理解must-understand”的扩展extensions。但是，这种扩展机制并没有得到客户端的应用，而且这个所谓的“必须理解”的要求也没有得到很多服务器的实现，致使这种扩展机制变得无用useless。本规范已经移除了这种扩展机制以简化 100-continue 的定义和处理。

5.1.2. Max-Forwards

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 头字段为 TRACE（章节 4.3.8）和 OPTIONS（章节 4.3.7）请求方法提供了一种方法来限制这个请求被代理所转发的次数。当客户端试图去追踪某个请求可能在请求链路的中部mid-chain转发失败了或者陷入循环的时候，Max-Forwards 将非常有用。 

  1. 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 头字段的 TRACE 或者 OPTIONS 请求的每一个中间人，在转发这个请求的之前，必须 检查并更新 Max-Forwards 的值。如果所接收到的值是 0，这个中间人 禁止 转发该请求，而是，必须 作为最终接收端final recipient来响应该请求。如果所接收到的 Max-Forwards 值大于 0，这个中间人 必须 在转发的消息里生成一个更新后的 Max-Forwards，其值可以为以下其中之一：

  • 所接收到的值减去 1；
  • 该接收端自身的 Max-Forwards 最大可支持的值。

A recipient MAY ignore a Max-Forwards header field received with any other request methods.

接收端 可以 忽略接收自其他请求方法里的 Max-Forwards 头字段。

译注：也就是说，应该仅在 TRACE 和 OPTIONS 请求里使用 Max-Forwards 头字段。

5.2. 条件句 / Conditionals

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

HTTP 的条件请求头字段conditional request fields【RFC7232】让客户端可以在目标资源的状态上设置一个前提条件precondition，使得如果前提条件不成立的话，该请求方法的语义所对应动作不会被执行。本规范所定义的每一种前提条件皆由从目标资源先前的表示形式representations那里获得的一系列验证器validators，与当前应用到已选表示形式的验证器的目前状态之间的比较来组成的（章节 7.2）。因此，这些前提条件以客户端的一个给定的已知状态作为参考，来评估目标资源的状态是否已经改变了。这种评估的结果依赖于请求方法的语义method semantics以及条件句的选择choice of conditional，其定义见【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]

5.3. 内容协商 / Content Negotiation

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.

下列请求头字段request header fields会被用户代理所发送以参与对响应内容的主动协商proactive negotiation，其定义见章节 3.4.1。在这些头字段里偏好设置（首选项）preferences会应用到响应里的所有内容上，这些内容包括：目标资源的表示形式、错误状态或处理中状态的表示形式、甚至是可能出现在协议内的混杂文本字符串。

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

5.3.1. 质量值 / Quality Values

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.

许多用于主动协商proactive negotiation的请求头字段都会使用一个名为 "q"（不区分大小写）的通用型参数common parameter，来分别向内容的对应类型的偏爱度preference赋予一个相对的“权重weight”。由于同名的参数 "q" 常常用在服务器配置里来对某个资源的各种可用的表现形式所对应的质量值赋予一个权重，因此，这个权重被称为“质量值quality value”（或者称为 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.

权重被规范化normalized为一个 0 到 1 范围内的实数值，其中，最小值是 0.001（优先级最低），最大值为 1（优先级最高），权重为 0 代表“不被接受”。如果没有出现参数 "q"，那么默认的权重为 1。 

  1. weight = OWS ";" OWS "q=" qvalue
  2. qvalue = ( "0" [ "." 0*3DIGIT ] )
  3.        / ( "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。应该要以相同的方式来限制这些权重的用户配置。

5.3.2. Accept

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 头字段来指定specify可以接受响应的哪些媒体类型media types。Accept 头字段可以用来表明indicate：请求是明确限定在一个期望类型desired types的小集合的，正如请求一个内嵌图片in-line image这种情况一样。 

  1. Accept = #( media-range [ accept-params ] )
  2.  
  3. media-range    = ( "*/*"
  4.                  / ( type "/" "*" )
  5.                  / ( type "/" subtype )
  6.                  ) *( OWS ";" OWS parameter )
  7. accept-params  = weight *( accept-ext )
  8. accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

译注：Accept 的 ABNF 定义使用了 # 列表规则，因此 Accept 接受多个媒体类型（media-range）及其对应的参数，每个媒体类型之间使用逗号分隔。媒体范围、媒体参数以及扩展参数之间使用分号分隔。

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/" 来表明该 type 类型的任何子类型。media-range 能够包含该 range 所接收的媒体类型参数。

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.

每个 media-range 后面可以跟随：0 个以上合适的媒体类型参数media type parameters（比如 charset）；一个可选的 "q" 参数用于指明一个相对的权重（章节 5.3.1）；以及在这些可选项其后还可以有 0 个以上扩展参数extension parameters。如果存在任何扩展（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 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".

注意： 之所以使用 "q" 参数名来分隔媒体参数与扩展参数是出于历史实践historical practice的原因。虽然这样做导致了 "q" 这个名字不能用来作为一个媒体类型的范围——基于 IANA 媒体类型登记表里的没有登记任何 "q" 参数，以及在 Accept 里极少使用媒体类型参数这些事实，相信不太可能会发生这种情况。将来新增的媒体类型会被劝阻登记任何命名为 "q" 的参数。

The example

例如： 

  1. 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".

上面例子可以解释为：“我首选（偏爱） audio/basic，但是，如果最佳可用best available的质量值调低 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 头字段，意味着用户代理接受任何媒体类型的响应。如果在一个请求里出现了 Accept，但响应没有任何可用的表现形式available representations所带有的媒体类型是被其列为可接受的，那么，源服务器可以遵守honor Accept 头字段的要求而返回一个 406 (Not Acceptable) 响应，也可以忽视disregard该头字段的要求就好像它并没有受到内容协商content negotiation的影响一样。

译注：也就是说，客户端提供了 Accept 头字段后并不能保证源服务器会按照它的要求来响应内容，选择权仍然在源服务器中。因为这是主动内容协商proactive content negotiation嘛。

A more elaborate example is

一个更复杂的例子： 

  1. Accept: text/plain; q=0.5, text/html,
  2.         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 类型的表示形式representation。如果 text/x-dvi 同样也不存在的话，发送 text/plain 类型的表示形式。”

译注：text/html 和 text/x-c 都没有指定 "q" 值，则默认权重为 1（最高优先级）。

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,

媒体的范围media ranges可以通过更明确的媒体范围，或者更明确的媒体类型来重写overridden。如果超过一个媒体范围应用到一个给定类型上，那么，优先使用最明确的那一个。例如： 

  1. Accept: text/*, text/plain, text/plain;format=flowed, */*

have the following precedence:

  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. ∗/∗

具有以下优先级precedence：

  • text/plain;format=flowed
  • text/plain
  • text/*
  • ∗/∗

译注：可以看出，在质量值相等的前提下，范围越精准，优先级越高。

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,

对应某个给定类型的媒体类型质量值，是通过查找匹配该类型的最高优先级的媒体范围来确定的。 

  1. Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
  2.         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

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.

注意： 对于确定的媒体范围来说，用户代理可能被提供一个默认的质量值集合。但是，除非该用户代理是一个无法与其他渲染中介rendering agents交互的封闭的系统，这个默认集合应该由用户来配置。

5.3.3. Accept-Charset

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 头字段来表明：在文本类型的响应内容中，它接受哪些字符集charsets。这个头字段让那些能够理解更加综合或者更加专业的字符集的用户代理，可以向那些能够以所述字符集来表示信息的源服务器，来表达这种信号：与之通信的客户端具备这种能力。 

  1. 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。以下是一个例子： 

  1. 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-Charset 的字段值里出现了特殊值 "" 的话，说明匹配任何未在该域里提及到的字符集。如果 Accept-Charset 的字段值里没有出现 ""，说明任何没有在该域里明确提及到的字符集是不为客户端所接受的。

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

请求里没有任何 Accept-Charset 头字段意味着该用户代理在响应里将接受的任何字符集。大多数通用型general-purpose的用户代理并不会发送 Accept-Charset，除非明确地配置为这样做，这是因为凭借用户代理的请求特征request characteristics（章节 9.7），一个支持的字符集的详细列表让一个服务器（相对 Accept-Charset 来说）更加轻松地标识一个个体individual。

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 头字段，但响应没有任何待选表现形式available representations所带有的字符集是被其列为可接受的，那么，源服务器可以遵守honor Accept-Charset 头字段的要求而返回一个 406 (Not Acceptable) 响应，也可以忽视disregard该头字段的要求就好像它并没有受到内容协商content negotiation的影响一样。

5.3.4. Accept-Encoding

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 头字段来表明：在响应中，它接受哪些响应内容编码content-codings（章节 3.1.2.1）。"identity" 标记用于作为一个“没有编码no encoding”的同义词以便在首选不编码的情况下进行通信。 

  1. Accept-Encoding  = #( codings [ weight ] )
  2. 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.

每个 codings 值都 可以 分别被给予一个相关联的质量值quality value来表示对应的编码的优先级，其定义见章节 5.3.1。如果 Accept-Encoding 的字段值里出现了符号 "*" 的话，说明匹配任何没有被明确列举在该域里的可用的内容编码available content-coding。

For example,

例如： 

  1. Accept-Encoding: compress, gzip
  2. Accept-Encoding:
  3. Accept-Encoding: *
  4. Accept-Encoding: compress;q=0.5, gzip;q=1.0
  5. 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 头字段，意味着该用户代理没有指定关于内容编码content-codings的偏好程度preferences。虽然这样做让服务器可以在响应里使用任何内容编码，但它并不意味着用户代理能够正确处理所有编码。

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.
  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".
  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".)
  4. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.

服务器使用以下规则来测试一个给定表示形式representation的某种内容编码是否为客户端所接受：

  • 如果请求里没有出现 Accept-Encoding，那么，可以认为任何内容编码皆为用户代理所接受。
  • 如果该表示形式没有内容编码，那么，默认是可接受，除非客户端使用以下方式来明确地排除无内容编码的情况：Accept-Encoding 的字段值以 "identity;q=0" 或者 "*;q=0" 开头，并且不再有比 "identity" 更明确的条目。
  • 如果该表示形式的内容编码是 Accept-Encoding 头字段里所列举的其中之一，那么，该内容编码可接受的，除非它伴随着的一个值为 0 的质量值qvalue（定义见章节 5.3.1，其值为 0 意味着“不接受not acceptable”）。
  • 如果多个内容编码都是可接受的，那么，带有质量值为最大且非 0 的内容编码作为首选。

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 头字段里其中一个组合条目值combined field-value为空，意味着用户代理并不想在响应里进行任何的内容编码。如果请求里出现了 Accept-Encoding 头字段，但响应没有任何可用的表示形式available representations所带有的内容编码是被其列为可接受的，那么，源服务器 应当 在没有任何内容编码的情况下发送响应。

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 的应用并不能识别或者遵循内容编码相关联的质量值。这意味着，质量值可能并不一定有用，并且它不能带有 x-gzip 或者 x-compress。

5.3.5. Accept-Language

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 头字段来表明：在响应中首选使用的自然语言natural language集合。语言标签language tags的定义见章节 3.1.3.1。 

  1. Accept-Language = 1#( language-range [ weight ] )
  2. language-range  = 
  3.           <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,

上述每个 language-range 都可以分别被给予一个相关联的质量值quality value来表示用户对由该范围所指定的语言的偏爱程度，其定义见章节 5.3.1。例如： 

  1. 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".

意为：“我首选丹麦语Danish，但也会接受英式英语British 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 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).

如果请求里没有任何 Accept-Language 头字段，意味着该用户代理将会在响应里接受任何语言。如果请求里出现了该头字段，但响应没有任何可用的表示形式avaliable representations带有与之相匹配的语言标签，源服务器可以忽视disregard该头字段的要求就好像它并没有受到内容协商content negotiation的影响一样，可以遵守honor该头字段的要求而返回一个 406 (Not Acceptable) 响应。但是，并不鼓励使用后者这种方式，这是因为后者会阻止用户访问他们可能能够使用的内容（例如，使用翻译软件等）。

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

需要注意的是，某些接收端会将语言标签在 Accept-Language 里的列举顺序作为优先级的顺序（降序descending），特别是对于赋值为相等质量值（没有值时，等价于 q=1）的标签。但是，不能够依赖这种行为。为了一致性consistency以及最化大互操作性maximize interoperability，许多用户代理会对每种语言标签赋值一个唯一的质量值并且将它们以质量值降序的顺序列举到头字段里。对语言优先级列表的更多讨论能够在【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 定义了若干匹配方案matching schemes。实现可以以它们的要求来提供最合适的匹配方案。“基础过滤Basic Filtering”方案（【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).

在用户每次请求里的完整的语言偏爱preferences可能会和用户发送 Accept-Language 头字段的隐私期望privacy expectations相悖（章节 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.

正由于可理解性intelligibility是高度依赖于单独个体的，因此，用户代理需要让用户来控制语言偏爱preferences（可以通过用户代理自己的配置，也可以默认为用户所控制的系统设置）。不提供这些控制的用户代理 禁止 发送 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.

注意： 当需要选择语言偏爱的时候，用户代理应该向用户提供引导，这是因为用户很少熟悉上述语言匹配language matching相关的细节。例如，用户可以假设在选择 "en-gb" 的时候，如果英式英文不可用的情况下，用户代理会提供给他们任何类型的英文文档。在这种场景下，用户代理可以建议将 "en" 添加到列表中以为了更好的匹配行为。

5.4. 认证凭证 / Authentication Credentials

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]

5.5. 请求上下文/ Request Context

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…
Form Section 5.5.1
Referer Section 5.5.2
User-Agent Section 5.5.3

5.5.1. From

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

From 头字段包含一个控制现正发起请求的用户代理的人类用户的一个电子邮箱地址。该地址应该是机器可用的machine-usable，正如【RFC5322】章节 3.4 中的 "mailbox" 所定义的一样。 

  1. From    = mailbox
  2.  
  3. mailbox = <mailbox, see [RFC5322], Section 3.4>

An example is:

一个例子： 

  1. From: 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 头字段很少由非机器人non-robotic的用户代理所发送。用户代理 不应当 在未经用户显式配置（许可）的情况下发送 From 头字段，这是因为这样做可能会与用户的隐私利益privacy interests或者他们网站的安全策略security policy相冲突。

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.

机器人用户代理 应当 发送一个合法的 From 头字段，以便于如果服务器发生故障（比如该机器人发送了过多的、不必要的或者非法的请求）的时候，能够联系到负责运行该机器人的人。

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 头字段用于访问控制access control或者身份验证authentication，这是因为大多数接收端将会假定这个字段值是一种公共的信息。

5.5.2. Referer

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 头字段让用户代理可以指定一个 URI 引用，来表明：本次请求的目标 URItarget URI 是从哪一个资源那里获得的（也就是说，"referer" 指的是“引用页、引用者”，虽然这个字段名称存在拼写错误，本应该是 "referrer"）。用户代理在生成 Referer 头字段的时候，禁止 包含有 URI 引用里的 fragment 以及 userinfo 组件【RFC3986】。

译注：自【RFC7231】开始，已不再允许在 HTTP 和 HTTPS URI 中出现 userinfo （也就是说，用户名和密码）了，因为它在通信线路上传输时存在安全问题（见【RFC7230】附录 A.1）。而 fragment 标识是保留给客户端处理的，也不必提交到服务器上。 

  1. 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 头字段让服务器可以生成反向链接back-links到其他资源上，以达到简单分析simple analytics、日志记录logging、缓存优化optimized caching等目的。它还让弃用的或者打错的链接得以被发现，以便修复。某些服务器使用 Referer 头字段来作为拒绝来自其他网站的链接（即所谓的“深度链接”）或者限制跨站请求伪造cross-site request forgery（CSRF）的一种方法，但并不是所有请求都会包含这个头字段。

Example:

例如： 

  1. 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".

如果目标 URItarget URI是从一个资源那里获得的，但该资源并没有自己的 URI（比如，从键盘直接输入网址，或者在用户的书签/收藏夹内的某个条目），那么，用户代理 必须 排除掉 Referer 头字段，或者将它赋值为 "about:blank" 来发送。

译注：从网站统计的角度上看，用户通过在浏览器上直接输入网址或书签对网站进行访问的行为，就是所谓的直接访问。服务器的判断依据是请求是否有 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 请求中带有 Referer 字段值。更多安全注意事项见章节 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.

目前已经知道某些中间人intermediaries会在其发出的请求outgoing requests中任意移除 Referer 头字段。这样做会对抵御 CSRF 攻击造成干扰，这种副作用对用户来说更加有害。以限制limit Referer 的信息暴露为目的中间人扩展以及用户代理扩展应该将它们对 Referer 的改变限制restrict在特定的编辑范围内，比如使用化名pseudonyms来替换掉内部域名，或者截断 query 和/或 path 组件等。当 Referer 的字段值与请求目标request target使用的是相同的 scheme 和 host 的时候，中间人 不应当 修改或者删除 Referer 头字段。

5.5.3. User-Agent

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 头字段包含了发起请求originating the request的用户代理的相关信息。User-Agent 常被服务器用来帮助识别报告出互操作问题的范围，变通work around或调整tailor响应以避免个别用户代理的限制，以及分析浏览器或操作系统的使用情况等。用户代理 应当 在每个请求里包含一个 User-Agent 头字段，除非被明确配置为不要这样做。 

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

User-Agent 的字段值由一个或多个 product 标识符构成，每个 product 后面跟随着零个或多个 comment 注释（【RFC7230】章节 3.2），它们一起标识了该用户代理软件以及它的重要的子产品subproducts。按照惯例，这些 product 标识符是按其标识用户代理软件的重要性的降序顺序排列的。每个 product 标识符由一个名称和一个可选的版本构成。 

  1. product         = token ["/" product-version]
  2. 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).

发送端 应当 将所生成的 product 标识符限制为必要于标识该产品的那些标识符。发送端 禁止 将广告或其他非本质信息生成到 product 标识符内部。发送端 不应当 将不是一个 version 标识符的信息生成到 product-version 内部（也就是说，同一个产品名称的连续版本之间区别应该仅在于 product 标识符的 product-version 部分）。

Example:

例如： 

  1. 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").

用户代理 不应当 生成一个包含不必要的细粒度详尽信息fine-grained detail的 User-Agent 头字段，同时，应当 限制被第三方添加子产品到该字段中。太过长或详尽的 User-Agent 字段值会加大请求的延迟，以及违背用户意愿而被识别出（“指纹识别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.

同样，不鼓励实现implementations使用其他实现other implementations的 product 标记来断言declare（判断）与它们之间的兼容性compatibility，因为这样逃避circumvents了该字段的目的。如果一个用户代理伪装成另一个不同的用户代理，接收端可以假定这个用户代理故意想查看适用于被伪装的用户代理的响应，即使这些响应可能无法很好地适用于实际的用户代理。

6. 响应状态码 / Response Status Codes

The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.

状态码是为试图理解和满足请求而给出结果的一个三位整数。

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 状态码是可扩展的extensible。不要求 HTTP 客户端去理解所有已登记的状态码的意义，虽然这种理解明显是很值得的。但是，客户端 必须 理解所有状态码的种类，这些类型是由状态码的第一位数字来指明的。而且，客户端 必须 将它无法识别的unrecoginized状态码当作等同于它的种类的 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 (Bad Request) 响应来对待。响应消息通常会包含有一种表示形式representation来解释响应的状态。

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:

状态码的第一位数字定义了响应的种类。后两位数字并没有任何分类的作用。第一位数字有五个值：

6.1. 状态码概况 / Overview of Status Codes

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 里。下列原因短语reason phrases仅为建议，也就是说，在没有影响到协议的情况下，本地可以将它们替换为等效的其他短语。

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.

响应如果带有被定义为默认是可缓存的cacheable状态码（比如，本规范里的 200、203、204、206、300、301、404、405、410、414 和 501），那么，该响应能够被一个使用试探性过期heuristic expiration的缓存所复用，除非在请求方法的定义或者显式缓存控制explicit cache controls【RFC7234】里另有指定；其他所有状态码默认是不可缓存的not cacheable。

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。

6.2. 信息性 1xx / Informational 1xx

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 (Informational) 状态码种类表明：这是一个过渡响应interim response，用于在完成所请求的动作以及发送一个最终响应final response之前传递连接状态connection status或请求进展request progress。1xx 响应终止于状态行status-line之后的第一个空行empty line（空行标志着消息头部header section的结束）。由于 HTTP/1.0 并没有定义任何 1xx 状态码，因此，服务器 禁止 将 1xx 的响应发送到一个 HTTP/1.0 客户端上。

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.

客户端 必须 能够解析parse在接收到一个最终响应之前所接收到的一个或多个 1xx 响应，即使这个客户端并不期待expect接收。用户代理 可以 忽略意料之外的unexpected 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) 响应。

6.2.1. 100 继续 / 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) 状态码表明：一个请求的初始部分initial part已经被服务器接收，并且它还没有被服务器拒绝rejected。服务器打算在请求完全接收完毕并处理好之后再发送一个最终响应final response。

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.

当请求带有一个 Expect 头字段，而这个头字段含有一个 100-continue 期望expectation的时候，100 响应表明：服务器希望去接收请求的有效载荷request payload body，正如章节 5.1.1 讲述的那样。客户端应该继续发送请求的剩余部分并丢弃discard这个 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 期望expectation的 Expect 头字段，那么，客户端能够简单地丢弃这个过渡响应interm response。

6.2.2. 101 切换协议 / 101 Switching Protocols

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

101 (Switching Protocols) 状态码表明：服务器理解并愿意按照客户端的请求request（该请求经由 Upgrade 头字段来表达，见【RFC7230】章节 6.7）来改变本次连接正在使用的应用协议application protocol。服务器 必须 在响应里生成一个 Upgrade 头字段，来表明：从结束该 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 的好处可能会大于旧版本，或者在交付资源的时候切换到一种实时同步的协议real-time, synchronous protocol可能会更有优势。

6.3. 成功 2xx / Successful 2xx

The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.

2xx (Successful) 状态码种类表明：客户端的请求已经被成功接收received、理解understood和接受accepted。

6.3.1. 200 OK

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:

GET
a representation of the target resource;
HEAD
the same representation as GET, but without the representation data;
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.

200 (OK) 状态码表明：请求已经成功。200 响应里的有效载荷payload的含义取决于对应的请求方法request method。对于由本规范所定义的方法来说，有效载荷想要表达的含义可以总结为：

  • GET
  • 目标资源的一种表示形式representation；
  • HEAD
  • 与 GET 一样的表示形式，但没有表示形式数据representation data；
  • POST
  • 动作的状态（或者从动作获得的结果）的一种表示形式；
  • PUT, DELETE
  • 动作的状态的一种表示形式；
  • OPTIONS
  • 通信选项communication options的一种表示形式；
  • TRACE
  • 如同接收自终端服务器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.

除了回应给 CONNECT 的响应以外，200 响应总是带有一个有效载荷的，尽管源服务器 可以 生成一个长度为零的有效载荷。如果不想带有有效载荷，源服务器应该改为发送 204 (No Content) 响应。对于 CONNECT，不允许带有有效载荷是因为它的成功结果是一个隧道tunnel，而该隧道会在 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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.3.2. 201 已创建 / 201 Created

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 (Created) 状态码表明：请求已被实现fulfilled并且引起了一个或多个新资源new resources被创建。上述因请求而创建的主要资源primary resource会被一个在响应里的 Location 头字段所标识，或者，如果没有接收到 Location 头字段的话，则通过实际请求 URIeffective request 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 响应的有效载荷通常描述并链接到新创建的资源上。对于在 201 响应里的验证器头字段validator header fields（比如 ETag 和 Last-Modified）的意义和目的的讨论，见章节 7.2。

6.3.3. 202 已接受 / 202 Accepted

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 (Accepted) 状态码表明：请求已被接受处理，但处理尚未完成completed。最终可能也可能不会按照请求来行事，因为当实际进行处理的时候该请求可能被拒绝。HTTP 里没有任何的技巧facility可以从一个异步操作asynchronous operation中重发一个状态码。

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 响应有意含糊的。它的目的是为了让服务器可以接受一个请求来进行其他的处理（也许是一个每天仅运行一次的面向批量的处理）而不要求用户代理保持persist对服务器的连接直到完成该处理。随响应一起发送的表示形式representation应该描述该请求的当前状态并且指向（或者内嵌embed）一个状态监听器status monitor来向用户提供“请求将会在什么时候被实现”的评估。

6.3.4. 203 非权威信息 / 203 Non-Authoritative Information

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 (Non-Authoritative Information) 状态码表明：请求已成功，但是，由源服务器所生成的 200 (OK) 响应内的有效载荷已经被链路中的某个转换代理transforming proxy（【RFC7230】章节 5.7.2）修改过了。这个状态码让代理在对响应的有效载荷执行过转换时可以通知接收端，因为这种信息可能会影响到接收端以后对内容的相关决定。例如，今后对于该内容的缓存有效期验证请求cache validation requests可能只适用于沿着相同的请求路径（途经相同的代理）。

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 Transformation Applied 这个 Warning 码（【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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.3.5. 204 无内容 / 204 No Content

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 (No Content) 状态码表明：服务器已经实现fulfilled了这个请求，并且没有额外的内容需要发送到响应的有效载荷里。在执行apply完所请求的动作以后，响应头字段里的元数据metadata会引用目标资源及其选定的表示形式selected representation。

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.

例如，在回应给某个 PUT 请求的响应里，如果该响应带一个 204 状态码，并且包含有一个 ETag 头字段，说明这个 PUT 请求已被成功执行并且 ETag 的字段值所包含的 entity-tag 是那个目标资源的新的表示形式new representation。

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 响应让服务器可以去指出动作已被成功对目标资源应用（执行）apply，而这意味着用户代理并不需要切换它当前的“文档视图”（如果有的话）。服务器假定用户代理会向它的用户提供与它自身接口相符的某些成功指示，并且会将响应里的所有新的或更新过的元数据应用apply到用户代理的活动表示形式active representation上。

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 响应结束于头字段之后的第一个空行，因为它并不能带有一个消息体message body。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.3.6. 205 重置内容 / 205 Reset Content

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 (Reset Content) 状态码表明：服务器已经实现fulfilled了这个请求，并且很希望用户代理将“文档视图”重置为原始状态——这将导致发起请求——以源服务器的响应作为重置后的结果。

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 响应做以下其中之一的处理：

  • 通过包含一个值为 0 的 Content-Length 头字段来表明：响应有一个长度为零的消息体；
  • 通过包含一个值为 chunked 的 Transfer-Encoding，并且消息体由单独一个长度为零的分块chunk组成，来表明：响应有一个长度为零的有效载荷；
  • 在发送空行来结束消息头部以后，马上关闭连接。

6.4. 重定向 3xx / Redirection 3xx

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 (Redirection) 状态码种类表明：需要用户代理采取进一步的动作才能实现fulfill这个请求。如果提供了一个 Location 头字段（章节 7.1.2），用户代理 可以 自动重定向redirect它的请求到 Location 的字段值所指定的 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).
  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.
  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.
  4. Redirection to a previously cached result, as in the 304 (Not Modified) status code.

重定向有若干类型：

  • 状态码为 301 (Moved Permanently)、302 (Found)、307 (Temporary Redirect) 的重定向表明：资源可能在 Location 头字段所提供的另一个不同 URI 上可用。
  • 状态码为 300 (Multiple Choices) 的重定向提供了对于匹配到的资源的一种选择，每种都能够表示原始的请求目标。
  • 状态码 303 (See Other)，重定向到由 Location 字段所标识的另一个不同资源上，能够表示回应给请求的一种间接响应indirect response。
  • 状态码 304 (Not Modified)，重定向到上一个缓存结果。

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

注意： 在 HTTP/1.0 中，301 (Moved Permanently) 和 302 (Found) 状态码是定义为上述第一种重定向类型的（【RFC1945】章节 9.3）。早期的用户代理有一个分歧——应用到重定向目标的请求方法是使用与原来请求的方法一样呢，还是改写rewrite为 GET 方法呢？虽然 HTTP 最初将 301 和 302 定义为前者语义（来匹配它在 CERN 的最初实现），将 303 (See Other) 定义为后者语义，但是主流实现通常将 301 和 302 也转化为后者语义。HTTP/1.1 第一个修订版新增了 307 (Temporary Redirect) 来表明前者语言，以免受到实现上分歧的影响。其后十多年以来，大多数用户代理仍然对 301 和 302 的重定向使用方法重写的方式（即后者语义），所以，当原始请求是 POST 的时候，本规范顺应了这种行为。

A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).

客户端 应当 检测并调停循环重定向cyclical redirections（也就是说，无限重定向循环）。

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.

注意： 本规范早期的版本推荐最多 5 次重定向（【RFC2068】章节 10.3）。内容开发者content developers需要意识到某些客户端可能实现了这种固定次数的限制。

6.4.1. 300 多重选择 / 300 Multiple Choices

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 (Multiple Choices) 表明：目标资源有一个以上的表示形式，每种都具有更加明确的标识符，并提供了备选表示形式相关的信息以便用户（或者用户代理）能够通过重定向它的请求到一个或多个那些标识符来选择最优的表示形式preferred representation。换句话说，服务器希望用户代理参与进响应式协商reactive negotiation来选择它需要的最合适的表现形式（章节 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.

如果服务器有一个最优选择preferred choice，那么它 应当 生成一个 Location 头字段来包含最优选择的 URI 引用。用户代理 可以 使用 Location 字段的值自动重定向。

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 响应里生成一个有效载荷来包含一个列表，列表中有各种表示形式元数据representation metadata以及 URI 引用，让用户或者用户代理可以从中选出一个最优表示形式。如果用户代理了解所提供的媒体类型的话，它 可以 自动从中选择一个。本规范并没有定义自动选择的具体格式，那是因为 HTTP 试图与它的有效载荷的定义保持正交orthogonal。在实践过程中，表示形式会以某种被认为是便于用户代理去解析的格式来提供——这取决于共享设计或内容协商content negotiation；又或者以某些普遍被接受的超文本格式来提供。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【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 和 Alternates （随后的一个提案）两者。有可能使用一系列的 Link 头字段【RFC5988】来表达上述列表，每个 Link 值都与备选有关，虽然其部署还是一个“鸡和蛋”的问题。

6.4.2. 301 永久移动 / 301 Moved Permanently

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 (Move Permanently) 状态码表明：目标资源已被分配assign到一个新的永久 URI 上，将来对本资源的任何引用都应该使用本次响应所提供的新 URIs 之一。对于具有链接编辑link-editing能力的客户端应该自动将链接到实际请求 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).

服务器 应当 在响应里生成一个 Location 头字段来包含新的永久 URI 引用中最优的那一个。用户代e在皮耶entation 可以 使用 Location 的字段值来自动重定向automatic redirection。服务器的响应有效载荷通常会包含一个简短的超文本注释note，其内有一个指向这个（或多个）新 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 (Temporary Redirect) 状态码来代替。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.4.3. 302 发现 / 302 Found

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 (Found) 状态码表明：目标资源临时处在一个不同的 URI 之下。因为重定向可以会再次改变，客户端应该在将来的请求中继续使用原来的实际请求 URIeffective request URI（而不是使用本次响应中 Location 字段所指的那个 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).

服务器 应当 在响应里生成一个 Location 头字段来包含这个不同的 URI 引用。用户代理 可以 使用 Location 的字段值来自动重定向。服务器的响应有效载荷通常会包含一个简短的超文本注释note，其内有一个指向这个（或多个）新 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 (Temporary Redirect) 状态码来代替。

6.4.4. 303 查看其他 / See Other

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 (See Other) 状态码表明：服务器让用户代理重新定向到一个不同的资源上，正如在 Location 的字段值里所示的 URI 上，其意图是提供一个间接indirect的响应到原始请求。用户代理可以执行一个检索请求retrieval request（如果使用 HTTP 的话就是一个 GET 或者 HEAD）来定位这个 URI，这样同样可以重定向，并呈现最终结果来作为这个原始请求original request的应答。需要注意的是在 Location 头字段里的新 URI 不被视为等同于实际请求 URIeffective request URI。

译注：300 的 Location 字段值所指的 URI 表示资源有多个表示形式，301 和 302 中 Location 的 URI 表示资源在不同的位置上，这些 URI 所代表是同一个资源。与上述状态码不同的是，303 中 Location 的 URI 所指的是另一个不同的资源，所以有“间接”的意义。同时，正因为 303 的实际请求 URI 所代表的资源与 Location 的 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 动作的输出结果可以将用户代理重定向到一个选定的资源上，因为这样做可以以一种能够被单独标识indentified、保存书签bookmarked、缓存cached的方式来提供这个 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.

回应给 GET 请求的一个 303 响应表明：源服务器不存在一个目标资源的表示形式representation能够通过 HTTP 来传输。尽管如此，Location 的字段值引用了另一个资源来描述这个目标资源，以便于向这个新资源发起一个检索请求时可以得到一个可用于接收端的表示形式而不必有任何暗示它（这个表示形式）代表了原始的目标资源。

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 响应的表示形式应该包含一个简短的超文本注释note，其内有一个与 Location 头字段相同的 URI 的超链接。

6.4.5. 305 使用代理 / 305 Use Proxy

The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B).

305 (Use Proxy) 状态码是本规范之前的版本所定义的，现在已经弃用（附录 B）。

6.4.6. 305 未使用 / 306 (Unused)

The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.

306 状态码是本规范之前的版本所定义的，已经不再使用，同时保留该状态码。

6.4.7. 307 临时重定向 / 307 Temporary Redirect

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 (Temporary Redirect) 状态码表明：目标资源临时处在一个不同的 URI 之下，并且如果用户代理执行自动重定向到该 URI 的话，禁止 改变请求方法。因为重定向可能随时会改变，客户端应该在将来的请求中继续使用原来的实际请求 URIeffective request URI（而不是使用本次响应中 Location 字段所指的那个 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).

服务器 应当 在响应里生成一个 Location 头字段来包含这个不同的 URI 引用。用户代理 可以 使用 Location 的字段值来自动重定向。服务器的响应有效载荷通常会包含一个简短的超文本注释note，其内有一个指向这个（或多个）新 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。本规范并没有（像 307 之于 302 一样）为 301 (Moved Permanently) 定义对应的等效版本（不过为此目的【RFC7238】定义了 308 (Permanent Redirect) 状态码）。

6.5. 客户端错误 / Client Error 4xx

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 (Client Error) 状态码种类表明：客户端貌似有错误。除了响应给 HEAD 请求的这种情况以外，服务器 应当 在其发送的响应里包含一个表示形式来解释这种错误情况error situation，以及这是暂时还是永久的状况condition。这些状态码适用于任何请求方法。用户代理 应当 向用户展示其内的任何表示形式。

6.5.1. 400 无效请求 / 400 Bad Request

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 (Bad Request) 状态码表明：由于某些被认为是客户端的错误，导致服务器无法cannot或者不会will not处理这个请求（比如，错误的请求句法syntax、无效的请求报文分帧framing、欺骗性的请求路由routing等）。

6.5.2. 402 要求付费 / 402 Payment Required

The 402 (Payment Required) status code is reserved for future use.

402 (Payment Required) 状态码保留为将来使用。

6.5.3. 403 禁止 / 403 Forbidden

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 (Forbidden) 状态码表明：服务器理解这个请求但拒绝授权。如果服务器希望公布“为什么这个请求被禁止”的话，可以在响应有效载荷response payload（如果有的话）里描述其原因。

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.

如果该请求提供了认证凭据authentication credentials，那么 404 表示服务器认为它们还不足以予以访问。客户端 不应当 使用相同的凭据来自动重复这个请求。客户端 可以 使用新的或不同的凭据来重复该请求。尽管如此，请求可能出于凭据不相关的其他原因而被禁止。

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 (Not Found) 来代替 403。

6.5.4. 404 没有找到 / 404 Not Found

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 (Not Found) 状态码表明：源服务器没有找到目标资源的一个当前表示形式current representation，或者不想公开它的存在。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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.5.5. 405 方法不允许 / 405 Method Not Allowed

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 (Method Not Allowed) 状态码表明：接收自请求行request-line的方法为源服务器所知，但不为目标资源所支持。源服务器 必须 在 405 响应里生成一个 Allow 头字段来包含目标资源目前所支持的一系列的方法。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.5.6. 406 不接受 / 406 Not Acceptable

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.

406 (Not Acceptable) 状态码表明：根据在这个请求里接收到的主动协商相关的头字段（章节 5.3）来看，目标资源没有一种用户代理能接受的acceptable当前表示形式current representation，而且服务器并不愿意提供一个默认的表示形式。

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.

服务器 应当 生成一个有效载荷来包含一个列表，列表中有各种可用的表示形式的特点及其对应的资源定位符，让用户或者用户代理可以从中选择一个最合适的。用户代理 可以 从该列表中自动选择automatically select最合适的表示形式。但是，本规范并没有为这种自动选择定义任何标准，见章节 6.4.1。

6.5.7. 408 请求超时 / 408 Request Timeout

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 (Request Timeout) 状态码表明：服务器并没有在等待时间内接收到一个完整的请求消息。由于 408 意味着服务器已经决定关闭连接而不是继续等待，因此，服务器 应当 在响应中发送一个 "close" 连接选项（【RFC7230】章节 6.1）。如果客户端有一个未偿付outstanding的请求（也就是说，服务器未响应该请求）正在连接中传输，那么，客户端 可以 在一个新的连接中重复该请求。

6.5.8. 409 冲突 / 409 Conflict

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 (Conflict) 状态码表明：由于这个请求与目标资源的当前状态存在冲突，请求无法完成。本状态码用在用户可能有能力解决冲突并且重新提交该请求的情况。服务器 应当 生成一个有效载荷来包含足够的信息，让用户可以识别出冲突的源头。

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 请求的响应里。例如，如果使用了版本控制versioning，并且将要被 PUT 的表示形式包含了对资源的变更，这些变更与一个更早的（第三方）请求相冲突，那么，源服务器可以使用一个 409 响应来表明它不能完成该请求。在这种情况下，响应的表示形式可能会包含有助于基于修订记录revision history来合并差异的信息。

6.5.9. 410 已不在 / 410 Gone

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

410 (Gone) 状态码表明：对目标资源的访问在源服务器上已经不再可用，并且这种状况很可能是永久的。如果源服务器并不了解，或者不容易确定，这种状况是否是永久的，那么，应该使用 404 (Not Found) 状态码来代替。

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 响应主要是为了辅助网站维护的工作——通过通知接收端这个资源是有意设为不可用的，并且服务器所有者server owners希望这些引用该资源的远程链接remote links得到删除。常见于限定时间的促销活动和属于个人的资源不再与源服务器的网站相关联的情况。不需要将所有永久不可用的资源都标记为 "gone" 或者将这些标记维持在任意长的时间里——那是留给服务器所有者来决定的。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.5.10. 411 要求长度 / 411 Length Required

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 (Length Required) 状态码表明：服务器拒绝接受这个没有定义 Content-Length （【RFC7230】章节 3.3.3）的请求。如果客户端在请求消息中添加了一个包含消息体message body长度的合法 Content-Length 头字段，那么，客户端 可以 重复这个请求。

6.5.11. 413 有效载荷过大 / 413 Payload Too Large

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 (Payload Too Large) 状态码表明：服务器拒绝处理这个请求，因为请求的有效载荷的大小超出了服务器所愿意或能够处理的限制。服务器 可以 关闭连接来阻止客户端继续这个请求。

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 头字段来表明：这只是暂时的，以及在什么时间以后客户端 可以 重试。

6.5.12. 414 URI 过长 / 414 URI Too Long

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 Too Long) 状态码表明：服务器拒绝服务这个请求，因为请求目标request-target（【RFC7230】章节 5.3）的长度超出了服务器所愿意解释interpret的限制。这种状况极少出现，仅可能发生在：当客户端将一个 POST 请求不恰当地转换为一个带有超长查询信息query information的 GET 请求的时候；当客户端坠入一个重定向“黑洞black hole”（比如，一个重定向的 URI 前缀指向到它自己的一个后缀上）的时候；当服务器被客户端试图挖掘潜在的安全漏洞的时候。

译注：重定向“黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。

译注：某些服务器使用了固定长度的缓冲来读取或操作请求 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.5.13. 415 不支持的媒体类型 / 415 Unsupported Media Type

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 (Unsupported Media Type) 状态码表明：源服务器拒绝服务这个请求，因为有效载荷处于某种格式，请求方法不支持将该种格式作用到目标资源上。这种格式问题可能是由于这个请求所指明的 Content-Type 或 Content-Encoding，或者直接检查数据得出的结果。

6.5.14. 417 期望错误 / 417 Expectation Failed

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 (Expectation Failed) 状态码表明：请求中的 Expect 头字段（章节 5.1.1）所给定的期望expectation不能被至少一个入站服务器inbound servers所完成meet。

6.5.15. 426 要求升级 / 426 Upgrade Required

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 (Upgrade Required) 状态码表明：服务器拒绝使用当前协议来执行这个请求，但是，在客户端升级到一种不同的协议后，它可能愿意这样做。服务器 必须 在 426 响应里带有一个 Upgrade 头字段来指明所要求的一个或多个协议（【RFC7230】章节 6.7）。

Example:

例如： 

  1. HTTP/1.1 426 Upgrade Required
  2. Upgrade: HTTP/3.0
  3. Connection: Upgrade
  4. Content-Length: 53
  5. Content-Type: text/plain
  6.  
  7. This service requires use of the HTTP/3.0 protocol.

6.6. 服务器错误 / Server Error 5xx

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 condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.

5xx (Server Error) 状态码种类表明：服务器意识到它有错误或者它无法执行所请求的方法。除了响应给 HEAD 请求这种情况以外，服务器 应当 在其发送的响应里包含一个表示形式来解释这种错误情况error situation，以及这是暂时还是永久的状况condition。用户代理 应当 向用户展示其内的任何表示形式。这些状态码适用于任何请求方法。

6.6.1. 500 服务器内部错误 / 500 Internal Server Error

The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

500 (Internal Server Error) 状态码表明：服务器遇到一种异常状况阻止了它实现fulfill这个请求。

6.6.2. 501 没有实现 / 501 Not Implemented

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 (Not Implemented) 状态码表明：服务器并不支持实现fulfill这个请求所需要的功能。当服务器无法识别出请求方法并且它无法支持任何资源的时候，响应这个状态码是很合适。

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 响应默认是可缓存的cacheable，也就是说，除非由请求方法的定义或者显式带有的缓存控制cache controls（【RFC7234】章节 4.2.2）另有指定。

6.6.3. 502 无效网关 / 502 Bad Gateway

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 (Bad Gateway) 状态码表明：当服务器充当一个网关或代理的时候，在它试图实现fulfill这个请求的时候，从一个站内服务器inbound server里接收到一个无效的响应。

6.6.4. 503 服务不可用 / 503 Service Unavailable

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 (Service Unavailable) 状态码表明：由于临时的过载overload或者计划好的维护maintenance，导致服务器当前无法处理这个请求，可能等一段时间后就会恢复过来。服务器 可以 在其发送的响应里带有一个 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 的存在并不意味着当服务器出现过载的时候必须使用它。某些服务器可能只是简单地拒绝连接。

6.6.5. 504 网关超时 / 504 Gateway Timeout

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 (Gateway Timeout) 状态码表明：当服务器充当一个网关或代理的时候，它并没有在限时内从上游服务器upstream server——为了完成complete这个请求而需要访问的服务器——接收到一个响应。

6.6.6. 505 HTTP 版本不支持 / 505 HTTP Version Not Supported

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 Version Not Supported) 状态码表明：服务器并不支持，或者拒绝支持，用在这个请求消息里的 HTTP 的主版本major version。服务器表明它不能或不愿意使用与客户端相同的 HTTP 主版本来完成这个请求，详情见【RFC7230】章节 2.6；而是使用这个错误消息。服务器 应当 为 505 响应生成一个表示形式来描述“为什么不支持那个版本”以及“服务器支持其他哪些协议”。

译注：HTTP 使用“<主版本>.<次版本>”这种编号方案numbering scheme来表明协议的版本，如 HTTP/1.0、HTTP/1.1 等。详情见【RFC7230】章节 2.6。

7. 响应头字段 / Response Header Fields

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.

除了放在状态行status-line的响应信息以外，响应头字段response header fields让服务器可以传递额外的响应相关信息。这些头字段给出了关于服务器、关于对目标资源的后续访问、或者关于相关联的资源的信息。

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.

虽然每种响应头字段都定义了含义，但通常情况下，更精确的语义可能经由请求方法request method以及（或者）响应状态码response status code来进一步优化。

7.1. 控制数据 / Control Data

Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.

响应头字段能够提供以下方面的控制数据：补充状态码（如 Location 头字段提供了 302 重定向所需的 URI）；指导缓存；指导客户端下一步去哪里。

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]

7.1.1. 诞生日期 / Origination Date

7.1.1.1. 日期时间格式 / Date/Time Formats

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 年前，总共有三种不同的格式常用于服务器来传达时间戳timestamps。为了兼容旧有的实现，所有这三种都定义在这里。首选的格式是互联网消息格式Internet Message Format【RFC5322】所使用的日期和时间规范——一种固定长度的、单一时区的时间格式。

译注：所谓“单一时区”是因为 IMF（Internet Message Format）日期和时间规范里的时区zone支持多时区（虽然定义为已淘汰），这里取其 obs-zone ABNF 规则里的一个子集，见【RFC5322】章节 3.3。 

  1. HTTP-date    = IMF-fixdate / obs-date

An example of the preferred format is

首选格式的一个例子： 

  1. Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

Examples of the two obsolete formats are

两种已淘汰的格式的例子： 

  1. Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
  2. 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 头字段里的时间戳值进行解析parse的时候，必须 接受所有这三种 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-date 的值表示一个世界标准时间Coordinated Universal Time（UTC）。上述三个例子中的前两例通过格林威治标准时间Greenwich Mean Time——UTC 名称的前身——的三个英文字母缩写 "GMT" 来表明是 UTC。而 asctime 格式（即上述第三例）假定时间是 UTC 的。发送端从本地时钟生成 HTTP-date 值的时候，应该使用 NTP（【RFC5905】）或者其他类似的协议来将本地时间同步为 UTC。

Preferred format:

首选的格式： 

  1. IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  2. ; fixed length/zone/capitalization subset of the format
  3. ; see Section 3.3 of [RFC5322]
  4.  
  5. day-name     = %x4D.6F.6E ; "Mon", case-sensitive
  6.              / %x54.75.65 ; "Tue", case-sensitive
  7.              / %x57.65.64 ; "Wed", case-sensitive
  8.              / %x54.68.75 ; "Thu", case-sensitive
  9.              / %x46.72.69 ; "Fri", case-sensitive
  10.              / %x53.61.74 ; "Sat", case-sensitive
  11.              / %x53.75.6E ; "Sun", case-sensitive
  12.  
  13. date1        = day SP month SP year
  14.              ; e.g., 02 Jun 1982
  15.  
  16. day          = 2DIGIT
  17. month        = %x4A.61.6E ; "Jan", case-sensitive
  18.              / %x46.65.62 ; "Feb", case-sensitive
  19.              / %x4D.61.72 ; "Mar", case-sensitive
  20.              / %x41.70.72 ; "Apr", case-sensitive
  21.              / %x4D.61.79 ; "May", case-sensitive
  22.              / %x4A.75.6E ; "Jun", case-sensitive
  23.              / %x4A.75.6C ; "Jul", case-sensitive
  24.              / %x41.75.67 ; "Aug", case-sensitive
  25.              / %x53.65.70 ; "Sep", case-sensitive
  26.              / %x4F.63.74 ; "Oct", case-sensitive
  27.              / %x4E.6F.76 ; "Nov", case-sensitive
  28.              / %x44.65.63 ; "Dec", case-sensitive
  29. year         = 4DIGIT
  30.  
  31. GMT          = %x47.4D.54 ; "GMT", case-sensitive
  32.  
  33. time-of-day  = hour ":" minute ":" second
  34.              ; 00:00:00 - 23:59:60 (leap second)
  35.  
  36. hour         = 2DIGIT               
  37. minute       = 2DIGIT               
  38. second       = 2DIGIT

Obsolete formats:

已淘汰的格式： 

  1. obs-date     = rfc850-date / asctime-date 
  2. rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
  3. date2        = day "-" month "-" 2DIGIT
  4.              ; e.g., 02-Jun-82
  5.  
  6. day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
  7.        / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
  8.        / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
  9.        / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
  10.        / %x46.72.69.64.61.79          ; "Friday", case-sensitive
  11.        / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
  12.        / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
  13.  
  14. asctime-date = day-name SP date3 SP time-of-day SP year
  15. date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
  16.              ; e.g., Jun  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-date 是区分大小写的。发送端 禁止 在一个 HTTP-date 里生成除在语法中明确添加了 SP 以外的额外空白。day-name、day、month、year 以及 time-of-day 的语义与互联网消息格式Internet Message Format里所定义同名结构的语义相一致（【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-date 格式的时间戳使用两位数字来表示年份，如果接收端接收到一个 rfc850-date 格式的时间戳，必须 将时间戳里看起来像是未来 50 年以上的年份作为过去最近具有这两位数字相同的年份来对待。

译注： 由于 2 位数字表示的年份无法表现出世纪，因此，要将一个 2 位数字表示的年份转换为 4 位数字表示的年份时可将这个 2 位数字的年份限定在距今前后 50 年内。如果这 2 位数与当前年的差超过 50 年，则认为是过去时间。

例如，假设当前年份为 2018 年，要转换的时间戳的月、日、时、分、秒以及毫秒数与当前瞬时时间一致（即不考虑除年份以外的因素）：

  • 如果 2 位数字的年份为 02，那么 02 比 18 小，则认为是过去时间，距今最近的 02 年是 2002 年，那么 2002 就是转换的结果；
  • 如果 2 位数字的年份为 20，那么 20 比 18 大，则认为是未来时间，且 2020 距今（2018）只相差 2 年，不超过 50 年，那么 2020 就是转换的结果；
  • 如果 2 位数字的年份为 68，那么 68 比 18 大，则认为是未来时间，且 2068 距今（2018）相差 50 年，不超过 50 年，那么 2068 就是转换的结果；
  • 如果 2 位数字的年份为 69，那么 69 比 18 大，则认为是未来时间，且 2069 距今（2018）相差 51 年，超过了 50 年，那么 1969 就是转换的结果。

再给一个详细的转换表：

2位数年份 在2017年时转换为 在2018年时转换为 在2020年转换为
1 2001 2001 2001
2 2002 2002 2002
16 2016 2016 2016
17 2017 2017 2017
18 2018 2018 2018
19 2019 2019 2019
20 2020 2020 2020
21 2021 2021 2021
22 2022 2022 2022
65 2065 2065 2065
66 2066 2066 2066
67 2067 2067 2067
68 1968 2068 2068
69 1969 1969 2069
70 1970 1970 2070
71 1971 1971 1971
72 1972 1972 1972
87 1987 1987 1987
99 1999 1999 1999

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.

鼓励接收端在解析parse时间戳的时候足够健壮robust，除非被字段的定义另有限制。例如，不定期地从某个非 HTTP 源通过 HTTP 转发的消息，可能生成互联网消息格式Internet Message Format所使用的日期和时间规范里的任何一种格式。

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 对时间戳的格式要求仅应用于它们在协议流里的用途。不要求实现implementations使用这些格式来进行用户展示、请求日志记录等。

7.1.1.2. Date

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.

Date 头字段表示消息诞生originated的所有日期和时间，与定义在【RFC5322】章节 3.6.1 里的诞生日期字段Origination Date Field（orig-date）具有相同的语义。它的字段值是一个 HTTP-date，正如章节 7.1.1.1 所定义。 

  1. Date = HTTP-date

An example is

一个例子： 

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

当生成一个 Date 头字段的时候，发送端 应当 将它的值生成为最接近消息生成的时间。理论上，该时间应该代表有效载荷就要生成好之前的时候。实践过程中，该时间可以生成为消息诞生过程中的任意时候。

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.

如果源服务器不具有记时功能clock capable来提供一个合理的接近当前 UTC 的时间，禁止 在其发送的响应里带有 Date 头字段。如果响应的状态码种类是 1xx (Informational) 或者 5xx (Server Error)，源服务器 可以 在响应里带有 Date 头字段。源服务器 必须 在所有其他情况下带有一个 Date 头字段。

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.

当带有记时功能的接收端接收到一个没有 Date 头字段的响应消息的时候，哪果响应被缓存或被转发到下游，服务器 必须 记录下它接收到响应的时间，并且附加一个对应的 Date 头字段到消息的头部。

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.

用户代理 可以 在请求里带有一个 Date 头字段，虽然一般不会这么做，除非认为它运载了有用的信息给到服务器。例如，某些 HTTP 的客户应用程序可能会运载一个 Date， 如果服务器期望通过它，基于用户代理与服务器时间上的不同，来调整对用户请求的解释interpretation的话。

7.1.2. Location

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 头字段用在某些响应里，来引用一个与这个响应有关系的特定资源。这种关系的类型由请求方法和状态码两者的语义相结合而定义。 

  1. 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-reference 组成。如果这个 URI-reference 是相对引用relative reference的形式（【RFC3986】章节 4.2），那么，字段的最终值通过将它相对于实际请求 URIeffective request URI进行引用解释resolving来计算得出（【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 (Created) 响应，Location 的值引用的是由于这个请求而创建的主要资源primary resource。对于 3xx (Redirection) 响应，Location 的值引用的是最优的目标资源，用于自动重定向请求。

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 (Redirection) 响应所提供的 Location 头字段值不带有 fragment 组件（【RFC3986】章节 3.5），用户代理 必须 将 Location 的值当作继承了用于生成请求目标的那个 URI 引用的 fragment 组件一样，来处理这个重定向（也就是说，这个重定向继承了原始引用original reference的 fragment，如果存在 fragment 的话）。

For example, a GET request generated for the URI reference "http://www.example.org/~tim&#34; might result in a 303 (See Other) response containing the header field:

例如，生成一个 GET 请求到 URI 引用 "http://www.example.org/~tim"，可能返回一个 303 (See Other) 响应，带有以下头字段： 

  1. Location: /People.html#tim

which suggests that the user agent redirect to "http://www.example.org/People.html#tim&#34;

意思是建议用户代理重定向到 "http://www.example.org/People.html#tim"。

Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry&#34; might result in a 301 (Moved Permanently) response containing the header field:

同样，生成一个 GET 请求到 URI 引用 "http://www.example.org/index.html#larry"，可能返回一个 301 (Moved Permanently) 响应，带有以下头字段： 

  1. Location: http://www.example.net/index.html

which suggests that the user agent redirect to "http://www.example.net/index.html#larry&#34;, preserving the original fragment identifier.

意思是建议用户代理重定向到 "http://www.example.net/index.html#larry"，保留了原来的 fragment 标识符。

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.

某些情况下，fragment 标识符出现在 Location 的值里是不太合适的。例如，在一个 201 (Created) 响应里的 Location 头字段期望提供的是一个针对于新创建资源的 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.

注意： 某些接收端试图从 Location 的无效 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.

Content-Location 头字段（章节 3.1.4.2）与 Location 的不同之处在于：Content-Location 引用的是有效载荷内的表示形式所对应的最明确的资源。因此，在一个响应里同时包含 Location 和 Content-Location 两个头字段是可能的。

7.1.3. Retry-After

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.

服务器在其发送的响应里带有 Retry-After 头字段表明：用户代理在发送后续请求之前应该等待多长时间。当 503 (Service Unavailable) 响应里带有 Retry-After，表明：服务预期在多长时间内对客户端不可用。当 3xx (Redirection) 响应里带有 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-date，也可以是接收到响应以后的延迟秒数。 

  1. Retry-After = HTTP-date / delay-seconds

A delay-seconds value is a non-negative decimal integer, representing time in seconds.

delay-seconds 的值是一个十进制非负整数，表示秒数。 

  1. delay-seconds  = 1*DIGIT

Two examples of its use are

两个例子： 

  1. Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  2. Retry-After: 120

In the latter example, the delay is 2 minutes.

在第二个例子中，延迟是 2 分钟。

7.1.4. Vary

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 头字描述了：在请求消息里，除了请求方法、Host 头字段、请求目标以外，还有什么部分可能会影响到源服务器对这个响应的选择和表示selecting and representing的处理。它的值可以由单独一个星号（"*"）构成，也可由一个头字段名称（不区分大小写）的列表构成。 

  1. Vary = "*" / 1#field-name

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 的字段值由以英文逗号分隔comma-separated的名称构成时，表明：所指名named的请求头字段，称为选择头字段selecting header fields，可能在选择表示形式representation过程中发挥了作用。可能作为选择头字段的字段不限于本规范所定义的那些。

For example, a response that contains

例如，一个响应包含了如下字段： 

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

表明：源服务器可能已经使用（或者说由于缺少）该请求的 Accept-Encoding 和 Accept-Language 字段作为决定因素来选择这个响应的内容。

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

源服务器可能出于以下两种目的来发送带有一个字段列表的 Vary：

  • 去告诉缓存接收端cache recipients它们，禁止 使用这个响应来满足后续的请求，除非后续请求带有这个列表所罗列的字段，并且对应的值与原来的请求的字段值相同（【RFC7234】章节 4.1）。换句话说，Vary 扩展缓存服务器用来对新请求与所存储的缓存条目进行匹配所需要的键key。
  • 去告诉用户代理接收端它们，这个响应受到内容协商content negotiation（章节 5.3）的影响，并且，如果后续请求在这个列表所罗列的头字段里提供额外的参数的话，会发送一个不同的表示形式（主动型协商proactive negotiation）。

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 头字段，除非这种改变不能被逾越crossed或者源服务器是被刻意配置为阻止缓存服务器的透明性cache transparency。例如，不需要在 Vary 里带有 Authorization 字段名，因为用户间across users的复用受到这个字段的约束constrained（【RFC7235】章节 4.2）。同样，如果源服务器认为这种改变对比 Vary 对缓存的性能损耗performance cost的影响来说不是那么重要的话，它可能会使用 Cache-Control 指令（【RFC7234】章节 5.2）来取代 Vary。

7.2. 验证器头字段 / Validator Header Fields

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.

验证器头字段validator header fields负责运载关于已选表示形式selected representation的元数据（章节 3）。回应给安全请求safe requests的响应中，验证器头字段描述了由源服务器所选定的表示形式。需要注意的是，根据状态码的语义，对于一个给定的响应的已选表示形式，不必和封装为响应有效载荷的表示形式相同。

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.

在回应给会改变状态state-changing的请求的成功响应里，验证器头字段描述了：作为处理这个请求的结果，这个新的表示形式已经替换了之前所选定的表示形式。

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 (Created) 响应里的 ETag 头字段传达了新创建的响应的表示形式的 entity-tag，以便它能够用在接下来的条件请求contional requests中来阻止“丢失更新lost update”的问题【RFC7232】。

Header Field Name Defined in…
ETag Section 2.3 of [RFC7232]
Last-Modified Section 2.2 of [RFC7232]

7.3. 认证质询 / Authentication Challenges

Authentication challenges indicate what mechanisms are available for the client to provide authentication credentials in future requests.

认证质询authentication challenges表明：在未来的请求当中，客户端有什么能用的机制来提供认证质询。

Header Field Name Defined in…
WWW-Authenticate Section 4.1 of [RFC7235]
Proxy-Authenticate Section 4.3 of [RFC7235]

7.4. 响应上下文 / Response Context

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

7.4.1. Allow

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 头字段列出了声明目标资源所支持的一系列方法。这个字段的目的是确切通知给接收端这个资源有哪些有效的请求方法。 

  1. Allow = #method

Example of use:

使用示例： 

  1. 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 (Method Not Allowed) 响应里生成一个 Allow 字段，也 可以 在任何其他响应中这样做。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 头字段，因为代理并不需要去了解所有这些方法，为了按照通用消息处理规则来处理它们。

7.4.2. Server

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 头字段包含了源服务器处理这个请求所使用的软件的相关信息。客户端常用它来协助识别所报告出互操作问题的范围，变通work around或调整tailor请求以避免个别服务器的限制，以及分析服务器或操作系统的使用情况等。源服务器 可以 在它的响应里生成一个 Server 字段。 

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

Server 的字段值由一个或多个 product 标识符构成，每个 product 后面跟随着零个或多个 comment 注释（【RFC7230】章节 3.2），它们一起标识了该源服务器软件以及它的重要的子产品subproducts。按照惯例，这些 product 标识符是按其标识源服务器软件的重要性的降序顺序排列的。每个 product 标识符由一个名称和一个可选的版本构成，正如章节 5.5.3 所述。

Example:

例如： 

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

源服务器 不应当 生成一个包含不必要的细粒度详尽信息fine-grained的 Server 字段，同时，应当 限制被第三方添加子产品到该字段中。太过长或详尽的 Server 字段值会加大响应的延迟，以及可能泄露内部信息细节使得它（稍微）更容易被攻击者找到和挖掘已知的安全漏洞。

8. IANA 注意事项 / IANA Considerations

8.1. 方法登记表 / Method Registry

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。

8.1.1. 手续 / Procedure

HTTP method registrations MUST include the following fields:

  • Method Name (see Section 4)
  • Safe ("yes" or "no", see Section 4.2.1)
  • Idempotent ("yes" or "no", see Section 4.2.2)
  • Pointer to specification text
  • Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

HTTP 方法的登记 必须 包括以下几个字段：

8.1.2. 新方法的注意事项 / Considerations for New Methods

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" 的 Content-Length 头字段，新方法的定义能够指定只允许一个长度为零的消息体。

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），以及，如果可以的话，当条件为否的时候服务器要如何响应。同样，如果新方法可能在部分响应partial response的语义（【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】所赋予的语义。

8.1.3. 登记 / Registrations

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

8.2. 状态码登记表 / Status Code Registry

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）状态码登记表》定义了响应状态码的标记（章节 4）的命名空间。这个状态码登记表已被创建并维护在 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 状态码登记手续。

8.2.1. 手续 / Procedure

A registration MUST include the following fields:

  • Status Code (3 digits)
  • Short Description
  • Pointer to specification text

登记 必须 包括以下字段：

  • 状态码（3 位数字）
  • 简短描述
  • 指向到规范文本的引用

Values to be added to the HTTP status code namespace require IETF Review (see [RFC5226], Section 4.1).

添加到 HTTP 状态码命名空间的值要求由 IETF 复审（见【RFC5226】章节 4.1）。

8.2.2. 新状态码的注意事项 / Considerations for New Status Codes

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 中的种类里。为了让已有的解析器parsers可以处理这个响应消息，新状态码不能禁用有效载荷，尽管它们能够要求一个长度为零的有效载荷。

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

新状态码的定义应该解释explain在什么请求条件下会导致回应这个状态码的响应（比如，各种请求头字段和（或者）请求方法的组合情况），以及这种响应所依赖的所有响应头字段（比如，什么字段是必要的，什么字段能够修改这种语义，以及当使用这个新状态码的时候，什么头字段的语义会被进一步优化）。

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.

新状态码的定义应该明确它是否是可缓存的。需要注意的是，所有状态码能够被缓存，仅当这个响应里带有明确的新鲜度信息freshness 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).

最后，新状态码的定义应该指明：有效载荷是否与一个被标识的资源identified resource有某些相关联的含义（章节 3.1.4.1）。

8.2.3. 登记 / Registrations

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

8.3. 头字段登记表 / Header Field Registry

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】的定义。

8.3.1. 新头字段的注意事项 / Considerations for New Header Fields

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.

头字段是一种“键:值”对key:value pairs，用于传达消息、有效载荷、目标资源、以及连接（也就是说是控制数据control data）相关的数据。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-" 前缀已被广泛滥用了，它的意图是仅用在私人软件proprietary software或者企业内部网络intranet中作为避免名称冲突的一种机制，因为这个前缀可以确保私有名称private names永远不会与新近登记的互联网名称Internet name相冲突，更多信息见【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]).

头字段的原始值里的所有前置leading空白或后置trailing空白将会在解析parsing时被移除（【RFC7230】章节 3.2.4）。对于字段值里“哪里会有前置或后置空白”的定义是非常重要的，必须使用一种容器句法container syntax包裹起来，比如 quoted-string （【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.

因为英文逗号（","）是作为一种字段值之间的通用定界符generic delimiter，如果允许在字段值里使用英文逗号的话，必须小心地对待。通常，如果组件定义为可以包含英文逗号，组件通常会使用双引号 quoted-string ABNF 规则来进行保护。

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（它们都可以包含英文逗号）可以安全地在字段值里运载： 

  1. Example-URI-Field: "http://example.com/a.html,foo",
  2.                    "http://without-a-comma.example.com/"
  3. 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.

需要注意的是，双引号定界符double-quote delimiters几乎总是与 quoted-string 规则一起使用，如果在双引号里使用另一种不同的句法规则的话，很可能会引发不必要的混淆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 的 Content-Type。参数值既允许使用无引号句法unquoted syntax（用作标记token），也允许使用引号句法quoted syntax（用作括号字符串quoted-string），使得接收端可以使用已有的解析组件。当允许使用上述两种形式的时候，参数值的含义应该不依赖于它所使用的句法（一个例子可以查看章节 3.1.1.1 关于处理媒体类型的参数中的注意点）。

Authors of specifications defining new header fields are advised to consider documenting:

  • Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).

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

  • 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.
  • Whether the field should be stored by origin servers that understand it upon a PUT request.
  • Whether the field semantics are further refined by the context, such as by existing request methods or status codes.
  • 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]).
  • Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
  • 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).
  • Whether the header field is useful or allowable in trailers (see Section 4.1 of [RFC7230]).
  • Whether the header field ought to be preserved across redirects.
  • Whether it introduces any additional security considerations, such as disclosure of privacy-related data.

建议定义新字段规范的作者们考虑注明以下信息：

  • 字段的值是单一的，还是它能够作为一个列表（以逗号作为分界，见【RFC7230】章节 3.2）。

    如果它没有使用列表句法，注明如何处置它在消息中出现多次的情况（合理的默认做法是忽略该字段，但这样做不一定总是最佳的选择）。 需要注意的是，中间人或者软件库可能会将多个相同的头字段合并为一，不管该字段的定义是否允许使用列表句法。一种健壮的格式使得接收端可以发现这咱情况（好例子："Content-Type"，英文逗号只能出现在引号字符串内部。不好的例子："Location"，英文逗号可以出现在一个 URI 里面）。

  • 头字段能够在什么条件之下被使用，比如，仅用于响应或请求，可以用于所有消息，仅用于回应给特定请求方法的响应里，等等。

  • 通过 PUT 请求而了解到该字段的源服务器是否应该存储这个字段。
  • 该字段的语义是否会被上下文进一步优化refined，比如通过已有的请求方法或者状态码等。
  • 该字段的名称是否适用于列举在 Connection 头字段里（也就是说，该头字段是否是用于“逐跳hop-by-hop”的，见【RFC7230】章节 6.1）。
  • 中间人在什么条件之下可以插入、删除、或者修改这个字段的值。
  • 该字段是否适用于列举在 Vary 响应头字段里（比如，当请求头字段被用作源服务器的内容选择算法的时候，见章节 7.1.4）。
  • 该字段是否有用于或者允许用在尾部trailer里（【RFC7230】章节 4.1）。
  • 重定向过程中，该字段是否应该被保留。
  • 该字段是否引入了任何额外的安全注意事项，比如泄漏了隐私相关的数据。

8.3.2. 登记 / Registrations

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
UserAgent 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) - Internet Engineering Task Force"。

8.4. 内容编码登记表 / Content Coding Registry

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。

8.4.1. 手续 / Procedure

Content coding registrations MUST include the following fields:

  • Name
  • Description
  • Pointer to specification text

内容编码的登记 必须 包括以下字段：

  • 名称
  • 描述
  • 指向到规范文本的引用

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

内容编码的名称 禁止 与传输编码transfer codings的名称重复（【RFC7230】章节 4），除非编码转换是相同的（正如定义在【RFC7230】章节 4.2 里的压缩编码compression codings一样）。

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.

添加到本命名空间的值要求由 IETE 复审（见【RFC5226】章节 4.1），并且 必须 与定义在本章节的内容编码content coding的目的相一致。

8.4.2. 登记 / Registrations

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

《HTTP 内容编码登记表》已更新为以下条目：

Name Description Reference
identity Reserved (synonym for "no encoding" in Accept-Encoding) Section 5.3.4

9. 安全注意事项 / Security Considerations

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 语义semantics及其使用在互联网上进行信息传输过程中相关的已知的安全注意事项。与消息句法syntax、解析parsing、以及路由routing相关的注意事项已在【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 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 语义相关的大多数安全注意事项指的是保护服务端server-side应用（HTTP 接口背后的代码）、保护用户代理处理经由 HTTP 接收到有效载荷、或者保护互联网的一般使用，而不是协议的安全性。网络应用安全性相关的最新研究的专题信息和链接由许多组织共同维护（比如，【OWASP】）。

9.1. 基于文件名称和路径名称的攻击 / Attacks Based on File and Path Names

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.

源服务器经常使用它们的本地文件系统来管理实际请求 URIeffective request URI 与资源表示形式resource representations之间的映射mapping。大多数文件系统file system没有对防范恶意文件名称或路径名称方面的设计。因此，当源服务器映射请求目标到文件、文件夹、或者目录的时候，源服务器需要避免访问对于文件系统来说具有特殊意义的那些名称。

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、以及其他操作系统，使用 ".." 作为路径组件来表明当前路径的上一层级目录，而且它们使用特殊命名specially named的路径或者文件名来发送数据到系统设备当中。类似的名称转换naming convertions可能存在于其他类型的存储系统之间。同样，当对非法或意外字符进行处理、对已经分解的字符进行重排、以及对不区分大小写的名称进行大小写规范化的时候，本地存储系统有一个令人恼火的倾向是，相对于安全性，它更看重用户友好度。

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.

基于这种特殊名称的攻击倾向于侧重拒绝服务攻击denial-of-service（比如，告诉服务器去读取 COM 端口的数据）或者泄露disclosure服务器并不想提供的配置和源文件。

9.2. 基于命令、代码、查询注入 / Attacks Based on Command, Code, or Query Injection

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 里使用参数来作为标识系统服务identifying system services、选择数据库条目、或者选择数据源的一种方法。但是，不能相信接收自一个请求的数据。攻击者可以构建任何请求数据元素（方法、请求目标、头字段或者消息体）来包含恶意数据，当这些恶意数据经过一个命令执行器command invocation、语言解释器language interpreter、或者数据库接口database interface的时候，恶意数据可能会被它们误解为一个命令、代码、或者查询条件。

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.

例如，如果额外的数据库查询语言query language是由请求目标的某部分或者某些头字段（比如，Host、Referer 等）来插入的，那么，这里常常会发生 SQL 注入攻击。如果在一个 SELECT 语句statement中直接使用接收自请求的数据，查询语言可能会被解释为一个数据库命令，而不是一个简单的字符串。这种实现缺陷implementation vulnerability是非常普遍的，尽管很容易预防。

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.

通常，资源实现应该避免在上下文中使用会被处理或解释为指令instructions的请求数据。参数应该与固定的字符串进行对比，并且按照这个对比结果来行事，而不是直接丢给不检测是否为可信数据的接口当中。接收到不是基于固定参数的数据的时候，应该小心地过滤掉或者对它们进行编码，以避免造成误解。

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.

类似的注意事项同样适用于当请求数据被存储并延后处理的情况，比如在日志文件、监听工具内；也适用于当请求数据被包含在一种允许内嵌脚本embedded scripts的数据格式中的情况。

9.3. 个人信息的泄露 / Disclosure of Personal Information

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.

客户端通常会知道大量的个人信息，包括用户所提供的用于与资源进行交互的信息（比如，用户的名称、位置、邮件地址、密码、加密密钥等）以及用户长久以来的浏览活动相关的信息（比如，历史记录、收藏夹等）。实现需要阻止个人信息的意外泄漏。

9.4. URLs 敏感信息的泄露 / Disclosure of Sensitive Information in URLs

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.

服务的创造者authors of services应该避免基于 GET 的表单来提交敏感数据，因为那些数据将会放置到请求目标request-target里。很多已有的服务器、代理、以及用户代理，会在可能被第三方观察到的地方记录或者显示请求目标。这些服务应该改为使用基于 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 头字段将导致请求的上下文告诉给了目标网站，因此，它可能会泄漏reveal用户的即时浏览历史的相关信息，以及在其引用的资源 URI 中所能查找到的任何个人信息。关于 Referer 头字段的限制描述在章节 5.5.2 中，以指出它的一些安全注意事项。

9.5. 重定向后段落的泄露 / Disclosure of Fragment after Redirects

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 引用中所使用的 fragment 标识符不会在请求中被发送，但是，实现者应该要意识到，对于用户代理、以及响应所导致执行的扩展或脚本来说，它们是可见的。实践中，当发生一个重定向，并且原始请求的 fragment 标识符被 Location （章节 7.1.2）里的新引用所继承的时候，这样可能会导致一个网站的 fragment 泄漏到另一个网站当中。如果第一个网站的 fragment 使用了个人信息，它应该保证重定向到其他网站时包含一个（可能为空的） fragment 组件以阻止这种继承。

9.6. 产品信息的泄露 / Disclosure of Product Information

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.

User-Agent （章节 5.5.3）、Via （【RFC7230】章节 5.7.1）、以及 Server （章节 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.

当代理充当网络防火墙network firewall的一个门户的时候，应该采取特殊的措施来预防可能标识到防火墙内部主机的头部信息的传递。Via 头字段让中间人可以将敏感的机器名称machine names替换为化名pseudonyms。

9.7. 浏览器指纹识别 / Browser Fingerprinting

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.

浏览器指纹识别是一系列的技术以通过用户代理所特有的一组特征characteristics，长久地具体的用户代理进行识别。这些特征可能包含它的 TCP 行为、特色功能feature capabilities、以及脚本环境scripting environment等相关信息，不过这里特别感兴趣的是这一组经由 HTTP 来传达的唯一特征。指纹识别被认为是一种隐私问题，因为它启用了对一个用户代理的行为长时间的跟踪，对比于其他用户能够控制的数据收集的方式（比如，cookies）来说，用户无法左右指纹识别。许多通用的用户代理（也就是说，网页浏览器）已采取措施来减少它们的指纹识别。

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 designed to enable re-identification, so fingerprinting concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.

有大量的请求头字段可能泄漏信息给服务器，这些信息足以服务器启用指纹识别以唯一标识一个用户代理。From 头字段是最明显的，虽然 From 预期只会在用户希望自我识别self-identification的时候才会被发送。同样，Cookie 头字段是刻意设计为启用重新识别re-identification的，所以，指纹识别仅适用于 cookies 被用户代理的配置所禁用的情况。

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.

User-Agent 头字段可能包含足够的信息，通常当结合其他特征，特别是当用户代理发送用户的系统或扩展的过多细节的时候，可以唯一标识一个具体的设备。然而，用户最没有预料到的唯一信息的来源是主动型协商（章节 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.

除了指纹识别问题之外，Accept-Language 头字段的具体使用也会泄漏用户认为是隐私性质的信息。例如，了解给定语言集合的人可能与一个具体的种族群体密切相关。对于一个用户代理来说，限制这种失去隐私loss of privacy的一种途径可以是省略 Accept-Language 头字段的发送，除了加入进白名单的网站列表以外，也许在删除表明语言可能有用于内容协商的 Vary 头字段之后经由用户代理和服务器两者之间的交互。

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.

在代理用于加强隐私保护的环境中，用户代理应该保守地conservative发送用于主动协商的头字段。提供对头字段高度配置功能的通用型用户代理应该告知用户：如果提供了过多的头字段细节的话，用户可能会失去隐私loss of privacy。作为一种极端隐私的措施，代理可以在中转请求的时候，过滤掉所有主动协商的头字段。

10. 鸣谢 / Acknowledgements

See Section 10 of [RFC7230].

见【RFC7230】章节 10。

11. 参考资料 / References

11.1. 规范性参考资料 / Normative References

  • [RFC2045]
  • Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.
  • [RFC2046]
  • Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.
  • [RFC2119]
  • Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
  • [RFC3986]
  • Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.
  • [RFC4647]
  • Phillips, A., Ed. and M. Davis, Ed., “Matching of Language Tags”, BCP 47, RFC 4647, September 2006.
  • [RFC5234]
  • Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.
  • [RFC5646]
  • Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, September 2009.
  • [RFC6365]
  • Hoffman, P. and J. Klensin, “Terminology Used in Internationalization in the IETF”, BCP 166, RFC 6365, September 2011.
  • [RFC7230]
  • Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014.
  • [RFC7232]
  • Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, June 2014.
  • [RFC7233]
  • Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, RFC 7233, June 2014.
  • [RFC7234]
  • Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, June 2014.
  • [RFC7235]
  • Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, June 2014.

11.2. 信息性参考资料 / Informative References

  • [BCP13]
  • Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, January 2013.
  • [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.
  • [BCP90]
  • lyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.
  • [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/.
  • [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.
  • [RFC1945]
  • Berners-Lee, T., Fielding, R., and H. Nielsen, “Hypertext Transfer Protocol – HTTP/1.0”, RFC 1945, May 1996.
  • [RFC2049]
  • Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples”, RFC 2049, November 1996.
  • [RFC2068]
  • Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2068, January 1997.
  • [RFC2295]
  • Holtman, K. and A. Mutz, “Transparent Content Negotiation in HTTP”, RFC 2295, March 1998.
  • [RFC2388]
  • Masinter, L., “Returning Values from Forms: multipart/form-data”, RFC 2388, August 1998.
  • [RFC2557]
  • Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”, RFC 2557, March 1999.
  • [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.
  • [RFC2774]
  • Frystyk, H., Leach, P., and S. Lawrence, “An HTTP Extension Framework”, RFC 2774, February 2000.
  • [RFC2817]
  • Khare, R. and S. Lawrence, “Upgrading to TLS Within HTTP/1.1”, RFC 2817, May 2000.
  • [RFC2978]
  • Freed, N. and J. Postel, “IANA Charset Registration Procedures”, BCP 19, RFC 2978, October 2000.
  • [RFC5226]
  • Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
  • [RFC5246]
  • Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, August 2008.
  • [RFC5322]
  • Resnick, P., “Internet Message Format”, RFC 5322, October 2008.
  • [RFC5789]
  • Dusseault, L. and J. Snell, “PATCH Method for HTTP”, RFC 5789, March 2010.
  • [RFC5905]
  • Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, June 2010.
  • [RFC5987]
  • Reschke, J., “Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters”, RFC 5987, August 2010.
  • [RFC5988]
  • Nottingham, M., “Web Linking”, RFC 5988, October 2010.
  • [RFC6265]
  • Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011.
  • [RFC6266]
  • Reschke, J., “Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)”, RFC 6266, June 2011.
  • [RFC7238]
  • Reschke, J., “The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)”, RFC 7238, June 2014.

A. HTTP 与 MIME 的区别 / Defferences between HTTP and MIME

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 Message Format【RFC5322】以及多用途互联网邮件扩展Multipurpose Internet Mail Extensions（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 环境的代理和网关需要意识到这些不同点，以及在必要的地方提供合适的转换conversions。

A.1. MIME-VERSION

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-Version 头字段来表明：这个消息使用的是 MIME 协议的哪一个版本来构建的。MIME-Version 头字段的使用表明：这个消息是与 MIME 协议完全一致的（正如【RFC2045】所描述的）。当将 HTTP 消息导出到严格的 MIME 环境中的时候，发送端有责任确保完全符合（在可能的地方）MIME 规范。

A.2. 转换为规范形式 / Conversion to Canonical Form

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 要求互联网邮件的正文部分body part在传输之前转换为规范的形式canonical form，如【RFC2049】章节 4 所述。本文档的章节 3.1.1.3 描述了 "text" 媒体类型的子类型在 HTTP 上传输时所允许的形式。【RFC2046】要求带有 "text" 类型的内容使用 CRLF 来表示换行符line breaks并禁止在换行符字符序列以外的地方单独使用 CR 或者 LF。而 HTTP 则允许在文本内容里以 CRLF、单纯的 CR 以及单纯的 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 所描述的 "text" 媒体类型以内的所有换行符翻译translate为 RFC 2049 的 CRLF 规范形式。要注意，Content-Encoding 的出现，以及 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.

除非在转换前的原始内容已经是以规范的形式canonical form存在，否则，这种转换会破坏所有应用到原始内容的密码校验和cryptographic checksums。因此，推荐在 HTTP 中有使用这种校验和checksums的所有内容都以规范的形式存在。

A.3. 日期格式的转换 / Conversion of Date Formats

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）来简化日期对比date comparison的处理。来自其他协议的代理以及网关应该确保任何 Date 头字段以符合 HTTP/1.1 格式的其中一种形式来出现，并且在必要的情况下重写这个日期。

译注：HTTP/1.1 共兼容三种日期格式，其中两种已经淘汰，见章节 7.1.1.1。

A.4. Content-Encoding 的转换 / Conversion of Content-Encoding

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 的 Content-Encoding 头字段等价的任何概念。因为这样起到修改媒体类型的作用了，来自 HTTP 去向符合 MIME 规范的协议的代理以及网关应该在转发这个消息之前改变 Content-Type 头字段的值，或者解码decode它的表示形式representation（某些对互联网邮件增加 Content-Type 功能的实验性应用程序使用了一个值为 ";conversions=<content-coding>" 的 media-type 参数来提供与 Content-Encoding 等价的功能。但是，这个参数并不是 MIME 标准的一部分）。

A.5. Content-Transfer-Encoding 的转换 / Conversion of Content-Transfer-Encoding

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 的 Content-Transfer-Encoding 字段。来从符合 MIME 规范的协议去向 HTTP 的代理以及网关需要在交付这个响应消息到 HTTP 客户端之前，移除任何 Content-Transfer-Encoding。

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 规范的协议的代理以及网关有责任确保这个消息是以安全传输safe transport在那种协议上所需的正确的格式和编码format and encoding。其中“安全传输”是由所使用的协议的限制来定义的。这种代理和网关应该使用一个适合的 Content-Transfer-Encoding 来转换以及标识这份数据，如果这样做会提高在目的地协议destination protocol上的安全传输的可能性的话。

A.6. MHTML 以及行长度限制 / MHTML and Line Length Limitations

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

与 MHTML【RFC2557】实现implementations共享代码的 HTTP 的实现，需要意识到 MIME 的对行长度的限制line length limitations。因为 HTTP 并没有这种限制，因此 HTTP 并不会将很长的行进行折叠fold。由 HTTP 所传输的 MHTML 消息依照 MHTML 的所有约定，包括：行长度限制和行折叠、规范化等，因为 HTTP 将消息体message-bodies作为有效载荷payload来传输，而且除了 "multipart/byteranges" 类型（【RFC7233】附录 A）以外，并不会解释它里边的内容或者任何 MIME 的头部行。

B. 相对 RFC 2616 的变化 / Changes from RFC 2616

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 语义划分为独立的文档——核心功能、条件请求、部分请求、缓存、以及认证。语言的一致性language conformance已经修订为清晰的目标要求，而且术语terminology已经改进为区分来自表示形式的有效载荷以及来自资源的表示形式。

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 里，如果这些语义与请求方法不一致的话，因为这是互操作错误interoperability failure的常见原因。（章节 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)

移除了 "text" 媒体类型默认的字符集是 ISO-8859-1 的要求；现在默认是对应的媒体类型的定义所说的那种。同样，从 Accept-Charset 头字段里移除了 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)

Content-Location 的定义已经改变为不再影响解释resolving相对 URI 引用时的基 URI，这是因为只有很少实现支持以及具有可能破坏内容协商的资源content-negotiated resources里的相对链接的不良影响。（章节 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】的方法中性method-neutral的解析算法parsing algorithm，已经放宽了 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)

CONNECT 方法的定义已从【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)

OPTIONS 和 TRACE 请求方法已经定义为是安全的。（章节 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 头字段的扩展机制，因为已广泛部署的实现都不支持这种机制。（章节 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 头字段仅能使用在 OPTIONS 以及 TRACE 方法中，之前是扩展方法同样可以使用它。（章节 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)

当没有引用任何适用的 URI 的时候，已经建议将 "about:blank" 这个 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)

现在，以下状态码是可缓存的（也就是说，在不用显式出现新鲜度信息freshness information的情况下，它们能够被缓存服务器所存储和复用）：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 (Created) 状态码的描述已经改变为考虑到超过一个资源被创建的可能性。（章节 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 (Non-Authoritative Information) 状态码的定义已经拓宽broadened为也包括有效载荷转换payload transformations的情况。（章节 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 不再对响应有效载荷response payloads以及用户交互user interaction有规范要求。（章节 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 (See Other) 状态码的描述已经改变为允许它被缓存，如果给定了显式的新鲜度信息的话，并且对于回应给 GET 的 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 (Use Proxy) 状态码已经被废弃，这是由于代理的带内in-band配置相关的安全问题。（章节 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 (Bad Request) 状态码已经放宽了定义以便它不用限制为句法错误syntax errors。（章节 6.5.1）

The 426 (Upgrade Required) status code has been incorporated from [RFC2817]. (Section 6.5.15)

426 (Upgrade Required) 状态码已从【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 所要求的目标已经降低为那些系统所生成generating的日期，而不是所有系统所发送sending的日期。（章节 7.1.1）

译注：对于 generate 与 sned 之间的区别，见【RFC7230】章节 2.5。

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 头字段的句法已经改变为允许所有 URI 引用，包括相对引用以及 fragment。还加上了一些澄清说明关于什么时候使用 fragment 是不合适的。（章节 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)

Allow 已经重组为一个响应头字段，在 PUT 请求中移除了指定 Allow 的选项。放宽了 Allow 的内容的相关要求，作为对应，不再要求客户端总是相信它的值。（章节 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].

移除了 Content-Disposition 头字段，因为现在它由【RFC6266】所定义。

The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.

移除了 Content-MD5 头字段，因为它与部分响应partial responses的实现不一致。

C. 引进的 ABNF / Imported ABNF

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 中的核心规则：ALPHA （字母）、CR （回车符）、CRLF （回车换行符）、CTL （控制字符）、DIGIT （十进制数字 0-9）、DQUOTE （双引号）、HEXDIG （十六进制数字 0-9/A-F/a-f）、HTAB （水平制表符）、LF （换行符）、OCTET （八位组字节）、SP （空白）以及 VCHAR （【USASCII】可见字符）。

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

The rules below are defined in [RFC7230]:

以下规则定义在【RFC7230】中： 

  1. BWS           = <BWS, see [RFC7230], Section 3.2.3>
  2. OWS           = <OWS, see [RFC7230], Section 3.2.3>
  3. RWS           = <RWS, see [RFC7230], Section 3.2.3>
  4. URI-reference = <URI-reference, see [RFC7230], Section 2.7>
  5. absolute-URI  = <absolute-URI, see [RFC7230], Section 2.7>
  6. comment       = <comment, see [RFC7230], Section 3.2.6>
  7. field-name    = <comment, see [RFC7230], Section 3.2>
  8. partial-URI   = <partial-URI, see [RFC7230], Section 2.7>
  9. quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
  10. token         = <token, see [RFC7230], Section 3.2.6>

D. ABNF 集合 Collected ABNF

In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].

下列 ABNF 规则集合中，列表规则是在【RFC7230】章节 1.2 所扩充的。 

  1. Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
  2.  OWS ( media-range [ accept-params ] ) ] ) ]
  3. Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
  4.  "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
  5. Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
  6.  ( codings [ weight ] ) ] ) ]
  7. Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
  8.  "," [ OWS ( language-range [ weight ] ) ] )
  9. Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
  10.  
  11. BWS = <BWS, see [RFC7230], Section 3.2.3>
  12.  
  13. Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
  14.  content-coding ] )
  15. Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
  16.  language-tag ] )
  17. Content-Location = absolute-URI / partial-URI
  18. Content-Type = media-type
  19.  
  20. Date = HTTP-date
  21.  
  22. Expect = "100-continue"
  23.  
  24. From = mailbox
  25.  
  26. GMT = %x47.4D.54 ; GMT
  27.  
  28. HTTP-date = IMF-fixdate / obs-date
  29.  
  30. IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
  31.  
  32. Location = URI-reference
  33.  
  34. Max-Forwards = 1*DIGIT
  35.  
  36. OWS = <OWS, see [RFC7230], Section 3.2.3>
  37.  
  38. RWS = <RWS, see [RFC7230], Section 3.2.3>
  39. Referer = absolute-URI / partial-URI
  40. Retry-After = HTTP-date / delay-seconds
  41.  
  42. Server = product *( RWS ( product / comment ) )
  43.  
  44. URI-reference = <URI-reference, see [RFC7230], Section 2.7>
  45. User-Agent = product *( RWS ( product / comment ) )
  46.  
  47. Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
  48.  ) )
  49.  
  50. absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
  51. accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
  52. accept-params = weight *accept-ext
  53. asctime-date = day-name SP date3 SP time-of-day SP year
  54.  
  55. charset = token
  56. codings = content-coding / "identity" / "*"
  57. comment = <comment, see [RFC7230], Section 3.2.6>
  58. content-coding = token
  59.  
  60. date1 = day SP month SP year
  61. date2 = day "-" month "-" 2DIGIT
  62. date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
  63. day = 2DIGIT
  64. day-name = %x4D.6F.6E ; Mon
  65.  / %x54.75.65 ; Tue
  66.  / %x57.65.64 ; Wed
  67.  / %x54.68.75 ; Thu
  68.  / %x46.72.69 ; Fri
  69.  / %x53.61.74 ; Sat
  70.  / %x53.75.6E ; Sun
  71. day-name-l = %x4D.6F.6E.64.61.79 ; Monday
  72.  / %x54.75.65.73.64.61.79 ; Tuesday
  73.  / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
  74.  / %x54.68.75.72.73.64.61.79 ; Thursday
  75.  / %x46.72.69.64.61.79 ; Friday
  76.  / %x53.61.74.75.72.64.61.79 ; Saturday
  77.  / %x53.75.6E.64.61.79 ; Sunday
  78. delay-seconds = 1*DIGIT
  79.  
  80. field-name = <comment, see [RFC7230], Section 3.2>
  81.  
  82. hour = 2DIGIT
  83.  
  84. language-range = <language-range, see [RFC4647], Section 2.1>
  85. language-tag = <Language-Tag, see [RFC5646], Section 2.1>
  86.  
  87. mailbox = <mailbox, see [RFC5322], Section 3.4>
  88. media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
  89.  ";" OWS parameter )
  90. media-type = type "/" subtype *( OWS ";" OWS parameter )
  91. method = token
  92. minute = 2DIGIT
  93. month = %x4A.61.6E ; Jan
  94.  / %x46.65.62 ; Feb
  95.  / %x4D.61.72 ; Mar
  96.  / %x41.70.72 ; Apr
  97.  / %x4D.61.79 ; May
  98.  / %x4A.75.6E ; Jun
  99.  / %x4A.75.6C ; Jul
  100.  / %x41.75.67 ; Aug
  101.  / %x53.65.70 ; Sep
  102.  / %x4F.63.74 ; Oct
  103.  / %x4E.6F.76 ; Nov
  104.  / %x44.65.63 ; Dec
  105.  
  106. obs-date = rfc850-date / asctime-date
  107.  
  108. parameter = token "=" ( token / quoted-string )
  109. partial-URI = <partial-URI, see [RFC7230], Section 2.7>
  110. product = token [ "/" product-version ]
  111. product-version = token
  112.  
  113. quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
  114. qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
  115.  
  116. rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
  117.  
  118. second = 2DIGIT
  119. subtype = token
  120.  
  121. time-of-day = hour ":" minute ":" second
  122. token = <token, see [RFC7230], Section 3.2.6>
  123. type = token
  124.  
  125. weight = OWS ";" OWS "q=" qvalue
  126.  
  127. year = 4DIGIT

索引 / Index

  • 1
    • 100 Continue (status code) 6.1, 6.2.1, 8.2.3
    • 100-continue (expect value) 5.1.1
    • 101 Switching Protocols (status code) 6.1, 6.2.2, 8.2.3
    • 1xx Informational (status code class) 6.2
  • 2
    • 200 OK (status code) 6.1, 6.3.1, 8.2.3
    • 201 Created (status code) 6.1, 6.3.2, 8.2.3, B
    • 202 Accepted (status code) 6.1, 6.3.3, 8.2.3
    • 203 Non-Authoritative Information (status code) 6.1, 6.3.4, 8.2.3, B
    • 204 No Content (status code) 6.1, 6.3.5, 8.2.3
    • 205 Reset Content (status code) 6.1, 6.3.6, 8.2.3
    • 2xx Successful (status code class) 6.3
  • 3
    • 300 Multiple Choices (status code) 6.1, 6.4.1, 6.5.6, 8.2.3
    • 301 Moved Permanently (status code) 6.1, 6.4.2, 8.2.3, B
    • 302 Found (status code) 6.1, 6.4.3, 8.2.3, B
    • 303 See Other (status code) 6.1, 6.4.4, 8.2.3, B
    • 305 Use Proxy (status code) 6.1, 6.4.5, 8.2.3, B
    • 306 (Unused) (status code) 6.4.6, 8.2.3
    • 307 Temporary Redirect (status code) 6.1, 6.4.7, 8.2.3
    • 3xx Redirection (status code class) 6.4, B
  • 4
    • 400 Bad Request (status code) 6.1, 6.5.1, 8.2.3, B
    • 402 Payment Required (status code) 6.1, 6.5.2, 8.2.3
    • 403 Forbidden (status code) 6.1, 6.5.3, 8.2.3
    • 404 Not Found (status code) 6.1, 6.5.4, 8.2.3
    • 405 Method Not Allowed (status code) 6.1, 6.5.5, 8.2.3
    • 406 Not Acceptable (status code) 6.1, 6.5.6, 8.2.3
    • 408 Request Timeout (status code) 6.1, 6.5.7, 8.2.3
    • 409 Conflict (status code) 6.1, 6.5.8, 8.2.3
    • 410 Gone (status code) 6.1, 6.5.9, 8.2.3
    • 411 Length Required (status code) 6.1, 6.5.10, 8.2.3
    • 413 Payload Too Large (status code) 6.1, 6.5.11, 8.2.3
    • 414 URI Too Long (status code) 6.1, 6.5.12, 8.2.3
    • 415 Unsupported Media Type (status code) 6.1, 6.5.13, 8.2.3
    • 417 Expectation Failed (status code) 6.1, 6.5.14, 8.2.3
    • 426 Upgrade Required (status code) 6.1, 6.5.15, 8.2.3, B
    • 4xx Client Error (status code class) 6.5
  • 5
    • 500 Internal Server Error (status code) 6.1, 6.6.1, 8.2.3
    • 501 Not Implemented (status code) 6.1, 6.6.2, 8.2.3
    • 502 Bad Gateway (status code) 6.1, 6.6.3, 8.2.3
    • 503 Service Unavailable (status code) 6.1, 6.6.4, 8.2.3
    • 504 Gateway Timeout (status code) 6.1, 6.6.5, 8.2.3
    • 505 HTTP Version Not Supported (status code) 6.1, 6.6.6, 8.2.3
    • 5xx Server Error (status code class) 6.6
  • A
    • Accept header field 3.1.1.1, 5.3, 5.3.2, 8.3.2
    • Accept-Charset header field 5.3, 5.3.3, 8.3.2, B
    • Accept-Encoding header field 3.1.2.1, 5.3, 5.3.4, 8.3.2, 8.4.2
    • Accept-Language header field 3.1.3.1, 5.3, 5.3.5, 8.3.2
    • Allow header field 4.1, 7.4, 7.4.1, 8.3.2, B
  • B
    • BCP13 3.1.1.1, 11.2
    • BCP178 8.3.1, 11.2
    • BCP90 8.3, 8.3.1, 11.2
  • C
    • cacheable 4.2.3
    • compress (content coding) 3.1.2.1
    • conditional request 5.2
    • CONNECT method 4.1, 4.3.6, 8.1.3, B
    • content coding 3.1.2.1
    • content negotiation 1
    • Content-Encoding header field 3.1, 3.1.2.1, 3.1.2.2, 8.3.2
    • Content-Language header field 3.1, 3.1.3.2, 8.3.2
    • Content-Location header field 3.1, 3.1.4.2, 4.3.3, 7.1.2, 8.3.2, B
    • Content-Transfer-Encoding header field A.5
    • Content-Type header field 3.1, 3.1.1.1, 3.1.1.5, 8.3.1, 8.3.2
  • D
    • Date header field 3.3, 7.1, 7.1.1.2, 8.3.2
    • deflate (content coding) 3.1.2.1
    • DELETE method 4.1, 4.3.5, 8.1.3
  • E
    • Expect header field 5.1, 5.1.1, 6.2.1, 6.5.14, 8.3.2, B
  • F
    • From header field 5.5, 5.5.1, 8.3.2
  • G
    • GET method 3, 3.1.4.2, 3.3, 4.1, 4.3.1, 8.1.3, B
    • Grammar
      • Accept 5.3.2
      • Accept-Charset 5.3.3
      • Accept-Encoding 5.3.4
      • accept-ext 5.3.2
      • Accept-Language 5.3.5
      • accept-params 5.3.2
      • Allow 7.4.1
      • asctime-date 7.1.1.1
      • charset 3.1.1.2
      • codings 5.3.4
      • content-coding 3.1.2.1
      • Content-Encoding 3.1.2.2
      • Content-Language 3.1.3.2
      • Content-Location 3.1.4.2
      • Content-Type 3.1.1.5
      • Date 7.1.1.2
      • date1 7.1.1.1
      • day 7.1.1.1
      • day-name 7.1.1.1
      • day-name-l 7.1.1.1
      • delay-seconds 7.1.3
      • Expect 5.1.1
      • From 5.5.1
      • GMT 7.1.1.1
      • hour 7.1.1.1
      • HTTP-date 7.1.1.1
      • IMF-fixdate 7.1.1.1
      • language-range 5.3.5
      • language-tag 3.1.3.1
      • Location 7.1.2
      • Max-Forwards 5.1.2
      • media-range 5.3.2
      • media-type 3.1.1.1
      • method 4.1
      • minute 7.1.1.1
      • month 7.1.1.1
      • obs-date 7.1.1.1
      • parameter 3.1.1.1
      • product 5.5.3
      • product-version 5.5.3
      • qvalue 5.3.1
      • Referer 5.5.2
      • Retry-After 7.1.3
      • rfc850-date 7.1.1.1
      • second 7.1.1.1
      • Server 7.4.2
      • subtype 3.1.1.1
      • time-of-day 7.1.1.1
      • type 3.1.1.1
      • User-Agent 5.5.3
      • Vary 7.1.4
      • weight 5.3.1
      • year 7.1.1.1
    • gzip (content coding) 3.1.2.1
  • H
    • HEAD method 3.1.4.2, 4.1, 4.3.2, 8.1.3
  • I
    • idempotent 4.2.2
  • L
    • Location header field 4.3.3, 6.4, 7.1, 7.1.2, 8.3.2, 9.5, B
  • M
    • Max-Forwards header field 4.3.7, 4.3.8, 5.1, 5.1.2, 8.3.2, B
    • MIME-Version header field 8.3.2, A.1
  • O
    • OPTIONS method 4.1, 4.3.7, 5.1.2, 8.1.3, B, B, B
    • OWASP 9, 11.2
  • P
    • payload 3.3
    • POST method 3.1.4.2, 3.3, 4.1, 4.3.3, 8.1.3
    • PUT method 3.1.4.2, 3.3, 4.1, 4.3.4, 8.1.3, B
  • R
    • Referer header field 5.5, 5.5.2, 8.3.2, 9.4, B
    • representation 3
    • REST 3, 4.1, 11.2
    • Retry-After header field 6.6.4, 7.1, 7.1.3, 8.3.2
    • RFC1945 6.4, 11.2
      • Section 9.3 6.4
    • RFC2045 3.1.1.3, 11.1, A, A.1
    • RFC2046 3.1.1.1, 3.1.1.4, 3.1.1.5, 11.1, A.2
      • Section 4.5.1 3.1.1.5
      • Section 5.1.1 3.1.1.4
    • RFC2049 11.2, A.2
      • Section 4 A.2
    • RFC2068 5.1.1, 6.4, 11.2
      • Section 10.3 6.4
    • RFC2119 1.1, 11.1
    • RFC2295 3.4, 11.2
    • RFC2388 3.1.1.4, 11.2
    • RFC2557 3.1.4.2, 11.2, A.6
      • Section 4 3.1.4.2
    • RFC2616 5.3.5, 11.2
      • Section 14.4 5.3.5
    • RFC2774 8.1.2, 11.2
    • RFC2817 8.2, 11.2, B, B, B
      • Section 7.1 8.2, B
    • RFC2978 3.1.1.2, 11.2
    • RFC3986 5.5.2, 7.1.2, 7.1.2, 11.1
      • Section 4.2 7.1.2
      • Section 5 7.1.2
    • RFC4647 5.3.5, 5.3.5, 5.3.5, 5.3.5, 11.1
      • Section 2.1 5.3.5
      • Section 2.3 5.3.5
      • Section 3 5.3.5
      • Section 3.3.1 5.3.5
    • RFC5226 8.1.1, 8.2.1, 8.4.1, 11.2
      • Section 4.1 8.1.1, 8.2.1, 8.4.1
    • RFC5234 1.2, 8.3.1, 11.1, C
      • Appendix B.1 C
    • RFC5246 4.3.6, 11.2
    • RFC5322 5.5.1, 5.5.1, 7.1.1.1, 7.1.1.1, 7.1.1.1, 7.1.1.2, 11.2, A
      • Section 3.3 7.1.1.1, 7.1.1.1
      • Section 3.4 5.5.1, 5.5.1
      • Section 3.6.1 7.1.1.2
    • RFC5646 3.1.3.1, 3.1.3.1, 3.1.3.1, 11.1
      • Section 2.1 3.1.3.1
    • RFC5789 4.3.4, 11.2
    • RFC5905 7.1.1.1, 11.2
    • RFC5987 8.3.1, 11.2
    • RFC5988 6.4.1, 11.2
    • RFC6265 4.3.8, 5.4, 11.2
    • RFC6266 11.2, B
    • RFC6365 1.2, 3.1.1.2, 11.1
    • RFC7230 1, 1.1, 1.2, 2, 2, 2, 3.1.2.1, 3.1.2.1, 3.1.2.1, 3.1.2.2, 3.1.4.1, 3.1.4.2, 3.3, 3.3, 3.3, 4.3.6, 4.3.7, 4.3.8, 4.3.8, 5.1, 5.1, 5.1.1, 5.5.3, 6.2.2, 6.3.4, 6.5.7, 6.5.10, 6.5.12, 6.5.15, 6.6.6, 7.4.2, 8.1.2, 8.3.1, 8.3.1, 8.3.1, 8.3.1, 8.3.1, 8.3.1, 8.3.1, 8.4, 8.4.1, 8.4.1, 9, 9.6, 10, 11.1, B, C, C, C, C, C, C, C, C, C, C, C, D
      • Section 1.2 D
      • Section 2.5 1.1
      • Section 2.6 6.6.6
      • Section 2.7 2, C, C, C
      • Section 3.2 5.5.3, 7.4.2, 8.3.1, 8.3.1, C
      • Section 3.2.3 C, C, C
      • Section 3.2.4 8.3.1
      • Section 3.2.6 8.3.1, C, C, C
      • Section 3.3.1 3.1.2.2, 3.3
      • Section 3.3 8.1.2
      • Section 3.3.2 3.3, 6.5.10
      • Section 4 8.4.1
      • Section 4.1 8.3.1
      • Section 4.2.1 3.1.2.1
      • Section 4.2 8.4, 8.4.1
      • Section 4.2.2 3.1.2.1
      • Section 4.2.3 3.1.2.1
      • Section 4.3 5.1
      • Section 4.4 3.3
      • Section 5.3 2, 4.3.6, 4.3.7, 6.5.12
      • Section 5.4 5.1
      • Section 5.5 2, 3.1.4.1, 3.1.4.2
      • Section 5.7.1 4.3.8, 9.6
      • Section 5.7.2 6.3.4
      • Section 6.1 6.5.7, 8.3.1
      • Section 6.6 5.1.1
      • Section 6.7 6.2.2, 6.5.15
      • Section 7 1.2, 8.3.1
      • Section 8.3.1 4.3.8
      • Section 9 9
      • Section 10 10
    • RFC7232 3, 4.1, 5.2, 5.2, 5.2, 5.2, 5.2, 5.2, 6.1, 6.1, 6.1, 7.2, 7.2, 7.2, 11.1
      • Section 2.2 7.2
      • Section 2.3 7.2
      • Section 3.1 5.2
      • Section 3.2 5.2
      • Section 3.3 5.2
      • Section 3.4 5.2
      • Section 4 6.1
      • Section 4.1 6.1
      • Section 4.2 6.1
      • Section 5 5.2
    • RFC7233 3.1.1.4, 3.3, 4.3.1, 4.3.4, 5.1, 5.2, 6.1, 6.1, 6.1, 7.4, 8.1.2, 11.1, A.6
      • Section 2.3 7.4
      • Section 3.1 5.1
      • Section 3.2 5.2
      • Section 4 6.1
      • Section 4.1 6.1
      • Section 4.2 3.3, 4.3.4
      • Section 4.4 6.1
      • Appendix A A.6
    • RFC7234 4.2.3, 4.3.1, 4.3.2, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 5.1, 5.1, 6.1, 6.3.1, 6.3.4, 6.3.4, 6.3.5, 6.4.1, 6.4.2, 6.5.4, 6.5.5, 6.5.9, 6.5.12, 6.6.2, 7.1, 7.1, 7.1, 7.1, 7.1.4, 7.1.4, 8.2.2, 11.1
      • Section 4.1 7.1.4
      • Section 4.2.1 4.3.3
      • Section 4.2.2 6.3.1, 6.3.4, 6.3.5, 6.4.1, 6.4.2, 6.5.4, 6.5.5, 6.5.9, 6.5.12, 6.6.2
      • Section 4.3.5 4.3.2
      • Section 4.4 4.3.4, 4.3.5
      • Section 5.1 7.1
      • Section 5.2 4.3.1, 4.3.2, 5.1, 7.1, 7.1.4
      • Section 5.3 7.1
      • Section 5.4 5.1
      • Section 5.5 6.3.4, 7.1
    • RFC7235 4.3.8, 5.4, 5.4, 5.4, 6.1, 6.1, 6.1, 7.1.4, 7.3, 7.3, 11.1
      • Section 3 6.1
      • Section 3.1 6.1
      • Section 3.2 6.1
      • Section 4.1 7.3
      • Section 4.2 5.4, 7.1.4
      • Section 4.3 7.3
      • Section 4.4 5.4
    • RFC7238 6.4.7, 11.2
  • S
    • safe 4.2.1
    • selected representation 3, 7.2
    • Server header field 7.4, 7.4.2, 8.3.2, 9.6
    • Status Codes Classes
      • 1xx Informational 6.2
      • 2xx Successful 6.3
      • 3xx Redirection 6.4, B
      • 4xx Client Error 6.5
      • 5xx Server Error 6.6
  • T
    • TRACE method 4.1, 4.3.8, 5.1.2, 8.1.3, B, B, B
  • U
    • User-Agent header field 5.5, 5.5.3, 7.4.2, 8.3.2, 9.6
  • V
    • Vary header field 3.4.1, 7.1, 7.1.4, 8.3.1, 8.3.2
  • X
    • x-compress (content coding) 3.1.2.1
    • x-gzip (content coding) 3.1.2.1

Author' Addresses

  1. Roy T. Fielding (editor)
  2. Adobe Systems Incorporated
  3. 345 Park Ave
  4. San Jose, CA 95110
  5. USA
  6. Email: fielding@gbiv.com
  7. URI: http://roy.gbiv.com/
  1. greenbytes GmbH
  2. Hafenweg 16
  3. Muenster, NW 48155
  4. Germany
  5. Email: julian.reschke@greenbytes.de
  6. URI: http://greenbytes.de/tech/webdav/
  1. 阿多（译者）

Footnotes:

1

Backlink，反向连接，参考 Wikipedia: Backlink。

2

Content Object Tree

a Content Object is a single piece of managed content. Often referred to as simply "content".

The suffx of "object" is often used specifically to differentiate an object from its defining content type. For example: The "2016 Annual Report" content object is based on the "Managed Document" content type.

a Content Tree is the aggregation of content in a hierarchical tree.

Each content object in the tree has a parent (except, of course, for the object at the base of the tree – the "root" object), zero or more siblings, and zero or more children. The tree can be used to represent relationships between content objects

– O'REILLY "Web Content Management, SYSTEMS, FEATURES, AND BEST PRACTICES" Deane Barker