Internet Engineering Task Force (IETF) J. Snell
Request for Comments: 7240 June 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Snell
Request for Comments: 7240 June 2014
Category: Standards Track
ISSN: 2070-1721
Prefer Header for HTTP
HTTP首选标头
Abstract
摘要
This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.
该规范定义了一个HTTP头字段，客户端可以使用该字段请求服务器在处理请求时采用某些行为。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7240.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7240.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Syntax Notation ............................................4
2. The Prefer Request Header Field .................................4
2.1. Examples ...................................................6
3. The Preference-Applied Response Header Field ....................7
4. Preference Definitions ..........................................8
4.1. The "respond-async" Preference .............................8
4.2. The "return=representation" and "return=minimal"
Preferences ................................................9
4.3. The "wait" Preference .....................................11
4.4. The "handling=strict" and "handling=lenient" Processing ...12
5. IANA Considerations ............................................13
5.1. The Registry of Preferences ...............................13
5.2. Initial Registry Contents .................................15
6. Security Considerations ........................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
1. Introduction ....................................................2
1.1. Syntax Notation ............................................4
2. The Prefer Request Header Field .................................4
2.1. Examples ...................................................6
3. The Preference-Applied Response Header Field ....................7
4. Preference Definitions ..........................................8
4.1. The "respond-async" Preference .............................8
4.2. The "return=representation" and "return=minimal"
Preferences ................................................9
4.3. The "wait" Preference .....................................11
4.4. The "handling=strict" and "handling=lenient" Processing ...12
5. IANA Considerations ............................................13
5.1. The Registry of Preferences ...............................13
5.2. Initial Registry Contents .................................15
6. Security Considerations ........................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
Within the course of processing an HTTP request, there are typically a range of required and optional behaviors that a server or intermediary can employ. These often manifest in a variety of subtle and not-so-subtle ways within the response.
在处理HTTP请求的过程中，服务器或中介通常可以采用一系列必需和可选的行为。这些通常在反应中以各种微妙和不太微妙的方式表现出来。
For example, when using the HTTP PUT method to modify a resource -- similar to that defined for the Atom Publishing Protocol [RFC5023] -- the server is given the option of returning either a complete representation of a modified resource or a minimal response that indicates only the successful completion of the operation. The selection of which type of response to return to the client generally has no bearing on the successful processing of the request but could, for instance, have an impact on what actions the client must take after receiving the response. That is, returning a representation of the modified resource within the response can allow the client to avoid sending an additional subsequent GET request.
例如，当使用HTTP PUT方法修改资源（类似于为Atom发布协议[RFC5023]定义的资源）时，服务器可以选择返回已修改资源的完整表示或仅指示操作成功完成的最小响应。选择返回给客户的响应类型通常与请求的成功处理无关，但可能会影响客户在收到响应后必须采取的行动。也就是说，在响应中返回已修改资源的表示形式可以允许客户端避免发送额外的后续GET请求。
Similarly, servers that process requests are often faced with decisions about how to process requests that may be technically invalid or incorrect but are still understandable. It might be the case that the server is able to overlook the technical errors in the request but still successfully process the request. Depending on the
类似地，处理请求的服务器通常面临如何处理请求的决策，这些决策可能在技术上无效或不正确，但仍然可以理解。服务器可能忽略了请求中的技术错误，但仍然成功地处理了请求。取决于
specific requirements of the application and the nature of the request being made, the client might or might not consider such lenient processing of its request to be appropriate.
申请的具体要求和提出的请求的性质，客户可能会或可能不认为它的请求的宽松处理是适当的。
While the decision of exactly which behaviors to apply in these cases lies with the server processing the request, the server might wish to defer to the client to specify which optional behavior is preferred.
虽然在这些情况下应用哪些行为的决定取决于处理请求的服务器，但服务器可能希望遵从客户机来指定首选哪些可选行为。
Currently, HTTP offers no explicitly defined means of expressing the client's preferences regarding the optional aspects of handling of a given request. While HTTP does provide the Expect header -- which can be used to identify mandatory expectations for the processing of a request -- use of the field to communicate optional preferences is problematic:
目前，HTTP没有提供明确定义的方法来表达客户端对处理给定请求的可选方面的偏好。虽然HTTP确实提供Expect标头（可用于标识处理请求的强制期望），但使用该字段来传递可选首选项是有问题的：
1. The semantics of the Expect header field are such that intermediaries and servers are required to reject any request that states unrecognized or unsupported expectations.
1. Expect header字段的语义要求中介和服务器拒绝任何声明未识别或不支持的期望的请求。
2. While the Expect header field is end to end, the HTTP specification requires that the header be processed hop by hop. That is, every interceding intermediary that handles a request between the client and the origin server is required to process an expectation and determine whether it is capable of appropriately handling it.
2. 虽然Expect header字段是端到端的，但HTTP规范要求逐跳处理报头。也就是说，处理客户机和源服务器之间的请求的每个中间层都需要处理一个期望，并确定它是否能够适当地处理该期望。
The must-understand semantics of the Expect header make it a poor choice for the expression of optional preferences.
Expect头的“必须理解”语义使其成为可选首选项表达式的糟糕选择。
Another option available to clients is to utilize Request URI query-string parameters to express preferences. However, any mechanism that alters the URI can have undesirable effects, such as when caches record the altered URI.
Another option available to clients is to utilize Request URI query-string parameters to express preferences. However, any mechanism that alters the URI can have undesirable effects, such as when caches record the altered URI.translate error, please retry
As an alternative, this specification defines a new HTTP request header field that can be used by clients to request that optional behaviors be applied by a server during the processing the request. Additionally, a handful of initial preference tokens for use with the new header are defined.
作为替代方案，该规范定义了一个新的HTTP请求头字段，客户端可以使用该字段请求服务器在处理请求期间应用可选行为。此外，还定义了一些用于新标头的初始首选项标记。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and includes, by reference, the "token", "word", "OWS", and "BWS" rules and the #rule extension as defined within Sections 3.2.1 and 3.2.4 of [RFC7230]; as well as the "delta-seconds" rule defined in Section 8.1.3 of [RFC7231].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号，并通过引用包括[RFC7230]第3.2.1节和第3.2.4节中定义的“令牌”、“单词”、“OWS”和“BWS”规则以及规则扩展；以及[RFC7231]第8.1.3节中定义的“增量秒”规则。
The Prefer request header field is used to indicate that particular server behaviors are preferred by the client but are not required for successful completion of the request. Prefer is similar in nature to the Expect header field defined by Section 6.1.2 of [RFC7231] with the exception that servers are allowed to ignore stated preferences.
首选请求头字段用于指示特定的服务器行为是客户端首选的，但不是成功完成请求所必需的。Preference在本质上类似于[RFC7231]第6.1.2节定义的Expect header字段，但允许服务器忽略声明的首选项。
ABNF:
荷兰银行：
Prefer = "Prefer" ":" 1#preference
preference = token [ BWS "=" BWS word ]
*( OWS ";" [ OWS parameter ] )
parameter = token [ BWS "=" BWS word ]
Prefer = "Prefer" ":" 1#preference
preference = token [ BWS "=" BWS word ]
*( OWS ";" [ OWS parameter ] )
parameter = token [ BWS "=" BWS word ]
This header field is defined with an extensible syntax to allow for future values included in the Registry of Preferences (Section 5.1). A server that does not recognize or is unable to comply with particular preference tokens in the Prefer header field of a request MUST ignore those tokens and continue processing instead of signaling an error.
此标题字段使用可扩展语法定义，以允许将来的值包含在首选项注册表中（第5.1节）。无法识别或无法遵守请求首选标头字段中特定首选标记的服务器必须忽略这些标记并继续处理，而不是发出错误信号。
Empty or zero-length values on both the preference token and within parameters are equivalent to no value being specified at all. The following, then, are equivalent examples of a "foo" preference with a single "bar" parameter.
首选项标记和参数内的空或零长度值等同于根本不指定任何值。下面是带有单个“bar”参数的“foo”首选项的等效示例。
Prefer: foo; bar
Prefer: foo; bar=""
Prefer: foo=""; bar
Prefer: foo; bar
Prefer: foo; bar=""
Prefer: foo=""; bar
An optional set of parameters can be specified for any preference token. The meaning and application of such parameters is dependent on the definition of each preference token and the server's implementation thereof. There is no significance given to the ordering of parameters on any given preference.
可以为任何首选项标记指定一组可选参数。这些参数的含义和应用取决于每个偏好令牌的定义及其服务器的实现。对于任何给定的偏好，参数的排序都没有意义。
For both preference token names and parameter names, comparison is case insensitive while values are case sensitive regardless of whether token or quoted-string values are used.
对于首选项标记名和参数名，比较不区分大小写，而值区分大小写，无论使用的是标记值还是带引号的字符串值。
The Prefer header field is end to end and MUST be forwarded by a proxy if the request is forwarded unless Prefer is explicitly identified as being hop by hop using the Connection header field defined by [RFC7230], Section 6.1.
首选标头字段是端到端的，如果请求被转发，则必须由代理转发，除非使用[RFC7230]第6.1节定义的连接标头字段将首选显式标识为逐跳。
In various situations, a proxy might determine that it is capable of honoring a preference independently of the server to which the request has been directed. For instance, an intervening proxy might be capable of providing asynchronous handling of a request using 202 (Accepted) responses independently of the origin server. Such proxies can choose to honor the "respond-async" preference on their own regardless of whether or not the origin is capable or willing to do so.
在各种情况下，代理可能会确定它能够独立于请求所指向的服务器来遵守首选项。例如，介入代理可能能够独立于源服务器使用202（已接受）响应提供请求的异步处理。这些代理可以自行选择遵守“响应异步”首选项，而不管源服务器是否有能力或愿意这样做。
Individual preference tokens MAY define their own requirements and restrictions as to whether and how intermediaries can apply the preference to a request independently of the origin server.
个人偏好令牌可以定义自己的需求和限制，以确定中介机构是否以及如何独立于源服务器将偏好应用于请求。
A client MAY use multiple instances of the Prefer header field in a single message, or it MAY use a single Prefer header field with multiple comma-separated preference tokens. If multiple Prefer header fields are used, it is equivalent to a single Prefer header field with the comma-separated concatenation of all of the tokens. For example, the following are equivalent:
客户机可以在一条消息中使用首选标头字段的多个实例，也可以使用带有多个逗号分隔首选标记的单个首选标头字段。如果使用多个首选标头字段，则它相当于一个带有逗号分隔的所有标记串联的首选标头字段。例如，以下是等效的：
Multiple Prefer header fields defining three distinct preference tokens:
多个偏好标头字段定义三个不同的偏好标记：
POST /foo HTTP/1.1
Host: example.org
Prefer: respond-async, wait=100
Prefer: handling=lenient
Date: Tue, 20 Dec 2011 12:34:56 GMT
POST /foo HTTP/1.1
Host: example.org
Prefer: respond-async, wait=100
Prefer: handling=lenient
Date: Tue, 20 Dec 2011 12:34:56 GMT
A single Prefer header field defining the same three preference tokens:
单个首选项标题字段定义相同的三个首选项标记：
POST /foo HTTP/1.1
Host: example.org
Prefer: handling=lenient, wait=100, respond-async
Date: Tue, 20 Dec 2011 12:34:56 GMT
POST /foo HTTP/1.1
Host: example.org
Prefer: handling=lenient, wait=100, respond-async
Date: Tue, 20 Dec 2011 12:34:56 GMT
To avoid any possible ambiguity, individual preference tokens SHOULD NOT appear multiple times within a single request. If any preference is specified more than once, only the first instance is to be considered. All subsequent occurrences SHOULD be ignored without
为了避免任何可能的歧义，单个偏好标记不应在单个请求中出现多次。如果多次指定任何偏好，则只考虑第一个实例。应忽略所有后续发生的事件，而不进行修改
signaling an error or otherwise altering the processing of the request. This is the only case in which the ordering of preferences within a request is considered to be significant.
发出错误信号或以其他方式改变请求处理。这是唯一一种认为请求中的首选项排序很重要的情况。
Due to the inherent complexities involved with properly implementing server-driven content negotiation, effective caching, and the application of optional preferences, implementers are urged to exercise caution when using preferences in a way that impacts the caching of a response and SHOULD NOT use the Prefer header mechanism for content negotiation. If a server supports the optional application of a preference that might result in a variance to a cache's handling of a response entity, a Vary header field MUST be included in the response listing the Prefer header field regardless of whether the client actually used Prefer in the request. Alternatively, the server MAY include a Vary header with the special value "*" as defined by [RFC7231], Section 8.2.1. Note, however, that use of the "Vary: *" header will make it impossible for a proxy to cache the response.
由于正确实施服务器驱动的内容协商、有效缓存和应用可选首选项所涉及的固有复杂性，当以影响响应缓存的方式使用首选项时，建议实现者谨慎行事，不应使用首选头机制进行内容协商。如果服务器支持首选项的可选应用程序，这可能会导致缓存对响应实体的处理出现差异，则响应中必须包含Vary header字段，列出首选项header字段，而不管客户端是否在请求中实际使用了prefere。或者，服务器可以包括一个带有特殊值“*”的Vary头，如[RFC7231]第8.2.1节所定义。但是请注意，使用“Vary:*”标头将使代理无法缓存响应。
Note that while Preference tokens are similar in structure to HTTP Expect tokens, the Prefer and Expect header fields serve very distinct purposes and preferences cannot be used as expectations.
请注意，虽然首选项标记在结构上与HTTP Expect标记类似，但Preference和Expect头字段的用途非常不同，首选项不能用作期望。
The following examples illustrate the use of various preferences defined by this specification, as well as undefined extensions for strictly illustrative purposes:
以下示例说明了如何使用本规范定义的各种首选项，以及用于严格说明目的的未定义扩展：
1. Return a 202 (Accepted) response for asynchronous processing if the request cannot be processed within 10 seconds. An undefined "priority" preference is also specified:
1. 如果在10秒内无法处理请求，则返回用于异步处理的202（已接受）响应。还指定了未定义的“优先级”首选项：
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async, wait=10
Prefer: priority=5
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async, wait=10
Prefer: priority=5
{...}
{...}
2. Use lenient processing:
2. 使用宽松处理：
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: Lenient
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: Lenient
{...}
{...}
3. Use of an optional, undefined parameter on the return=minimal preference:
3. 在return=minimal preference上使用可选的未定义参数：
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: return=minimal; foo="some parameter"
POST /some-resource HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: return=minimal; foo="some parameter"
{...}
{...}
The Preference-Applied response header MAY be included within a response message as an indication as to which Prefer tokens were honored by the server and applied to the processing of a request.
首选项应用响应报头可以包括在响应消息中，作为指示服务器接受哪些首选令牌并将其应用于请求的处理。
ABNF:
荷兰银行：
Preference-Applied = "Preference-Applied" ":" 1#applied-pref
applied-pref = token [ BWS "=" BWS word ]
Preference-Applied = "Preference-Applied" ":" 1#applied-pref
applied-pref = token [ BWS "=" BWS word ]
The syntax of the Preference-Applied header differs from that of the Prefer header in that parameters are not included.
Preference Applied标头的语法与Preference标头的不同之处在于不包括参数。
Use of the Preference-Applied header is only necessary when it is not readily and obviously apparent that a server applied a given preference and such ambiguity might have an impact on the client's handling of the response. For instance, when using either the "return=representation" or "return=minimal" preferences, a client application might not be capable of reliably determining if the preference was (or was not) applied simply by examining the payload of the response. In such a case, the Preference-Applied header field can be used.
只有当服务器应用了给定的首选项并且这种模糊性可能会影响客户端对响应的处理时，才需要使用Preference Applied标头。例如，当使用“return=representation”或“return=minimal”首选项时，客户端应用程序可能无法通过检查响应的有效负载来可靠地确定是否应用了首选项。在这种情况下，可以使用Preference Applied header字段。
Request:
请求：
PATCH /my-document HTTP/1.1
Host: example.org
Content-Type: application/example-patch
Prefer: return=representation
PATCH /my-document HTTP/1.1
Host: example.org
Content-Type: application/example-patch
Prefer: return=representation
[{"op": "add", "path": "/a", "value": 1}]
[{"op": "add", "path": "/a", "value": 1}]
Response:
答复：
HTTP/1.1 200 OK
Content-Type: application/json
Preference-Applied: return=representation
Content-Location: /my-document
HTTP/1.1 200 OK
Content-Type: application/json
Preference-Applied: return=representation
Content-Location: /my-document
{"a": 1}
{"a": 1}
The following subsections define an initial set of preferences. Additional preferences can be registered for convenience and/or to promote reuse by other applications. This specification establishes an IANA registry of preferences (see Section 5.1).
以下小节定义了一组初始首选项。为了方便和/或促进其他应用程序的重用，可以注册其他首选项。本规范建立了IANA首选项登记册（见第5.1节）。
The "respond-async" preference indicates that the client prefers the server to respond asynchronously to a response. For instance, in the case when the length of time it takes to generate a response will exceed some arbitrary threshold established by the server, the server can honor the "respond-async" preference by returning a 202 (Accepted) response.
“respond async”首选项表示客户端希望服务器异步响应响应。例如，当生成响应所需的时间长度超过服务器设置的某个任意阈值时，服务器可以通过返回202（已接受）响应来满足“respond async”首选项。
ABNF:
荷兰银行：
respond-async = "respond-async"
respond-async = "respond-async"
The key motivation for the "respond-async" preference is to facilitate the operation of asynchronous request handling by allowing the client to indicate to a server its capability and preference for handling asynchronous responses.
“respond async”首选项的主要动机是通过允许客户端向服务器指示其处理异步响应的能力和首选项，从而促进异步请求处理的操作。
An example request specifying the "respond-async" preference:
指定“响应异步”首选项的请求示例：
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async
{Data}
{Data}
An example asynchronous response using 202 (Accepted):
使用202的异步响应示例（已接受）：
HTTP/1.1 202 Accepted
Location: http://example.org/collection/123
HTTP/1.1 202 Accepted
Location: http://example.org/collection/123
While the 202 (Accepted) response status is defined by [RFC7231], little guidance is given on how and when to use the response code and the process for determining the subsequent final result of the operation is left entirely undefined. Therefore, whether and how any given server supports asynchronous responses is an implementation-specific detail that is considered to be out of the scope of this specification.
虽然[RFC7231]定义了202（已接受）响应状态，但对于如何以及何时使用响应代码给出了很少的指导，确定操作后续最终结果的过程完全没有定义。因此，任何给定的服务器是否以及如何支持异步响应都是一个特定于实现的细节，被认为超出了本规范的范围。
The "return=representation" preference indicates that the client prefers that the server include an entity representing the current state of the resource in the response to a successful request.
“return=representation”首选项表示客户端希望服务器在对成功请求的响应中包含表示资源当前状态的实体。
The "return=minimal" preference, on the other hand, indicates that the client wishes the server to return only a minimal response to a successful request. Typically, such responses would utilize the 204 (No Content) status, but other codes MAY be used as appropriate, such as a 200 (OK) status with a zero-length response entity. The determination of what constitutes an appropriate minimal response is solely at the discretion of the server.
另一方面，“return=minimal”首选项表示客户机希望服务器仅返回对成功请求的最小响应。通常，此类响应将利用204（无内容）状态，但可酌情使用其他代码，例如具有零长度响应实体的200（OK）状态。确定什么构成适当的最小响应完全由服务器决定。
ABNF:
荷兰银行：
return = "return" BWS "=" BWS ("representation" / "minimal")
return = "return" BWS "=" BWS ("representation" / "minimal")
When honoring the "return=representation" preference, the returned representation might not be a representation of the effective request URI when the request is affecting another resource. In such cases, the Content-Location header can be used to identify the URI of the returned representation.
当遵循“return=representation”首选项时，当请求影响另一个资源时，返回的表示可能不是有效请求URI的表示。在这种情况下，可以使用Content Location标头来标识返回表示的URI。
The "return=representation" preference is intended to provide a means of optimizing communication between the client and server by eliminating the need for a subsequent GET request to retrieve the current representation of the resource following a modification.
“return=representation”首选项旨在提供一种优化客户机和服务器之间通信的方法，它消除了在修改后检索资源当前表示形式的后续GET请求的需要。
After successfully processing a modification request such as a POST or PUT, a server can choose to return either an entity describing the status of the operation or a representation of the modified resource itself. While the selection of which type of entity to return, if any at all, is solely at the discretion of the server, the "return=representation" preference -- along with the "return=minimal" preference defined below -- allow the server to take the client's preferences into consideration while constructing the response.
成功处理修改请求（如POST或PUT）后，服务器可以选择返回描述操作状态的实体或已修改资源本身的表示。虽然选择返回哪种类型的实体（如果有的话）完全由服务器决定，但“return=representation”首选项——以及下面定义的“return=minimal”首选项——允许服务器在构建响应时考虑客户端的首选项。
An example request specifying the "return=representation" preference:
指定“return=representation”首选项的请求示例：
PATCH /item/123 HTTP/1.1
Host: example.org
Content-Type: application/example-patch
Prefer: return=representation
PATCH /item/123 HTTP/1.1
Host: example.org
Content-Type: application/example-patch
Prefer: return=representation
1c1
< ABCDEFGHIJKLMNOPQRSTUVWXYZ
---
> BCDFGHJKLMNPQRSTVWXYZ
1c1
< ABCDEFGHIJKLMNOPQRSTUVWXYZ
---
> BCDFGHJKLMNPQRSTVWXYZ
An example response containing the resource representation:
包含资源表示的响应示例：
HTTP/1.1 200 OK
Content-Location: http://example.org/item/123
Content-Type: text/plain
ETag: "d3b07384d113edec49eaa6238ad5ff00"
HTTP/1.1 200 OK
Content-Location: http://example.org/item/123
Content-Type: text/plain
ETag: "d3b07384d113edec49eaa6238ad5ff00"
BCDFGHJKLMNPQRSTVWXYZ
BCDFGHJKLMNPQRSTVWXYZ
In contrast, the "return=minimal" preference can reduce the amount of data the server is required to return to the client following a request. This can be particularly useful, for instance, when communicating with limited-bandwidth mobile devices or when the client simply does not require any further information about the result of a request beyond knowing if it was successfully processed.
相反，“return=minimal”首选项可以减少服务器在请求后返回到客户端所需的数据量。例如，当与有限带宽的移动设备通信时，或者当客户端除了知道请求是否被成功处理之外不需要关于请求结果的任何进一步信息时，这可能特别有用。
An example request specifying the "return=minimal" preference:
指定“return=minimal”首选项的请求示例：
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: return=minimal
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: return=minimal
{Data}
{Data}
An example minimal response:
最小响应示例：
HTTP/1.1 201 Created
Location: http://example.org/collection/123
HTTP/1.1 201 Created
Location: http://example.org/collection/123
The "return=minimal" and "return=representation" preferences are mutually exclusive directives. It is anticipated that there will never be a situation where it will make sense for a single request to include both preferences. Any such requests will likely be the result of a coding error within the client. As such, a request containing both preferences can be treated as though neither were specified.
“return=minimal”和“return=representation”首选项是相互排斥的指令。可以预见，在任何情况下，一个请求包含两个首选项都是有意义的。任何此类请求都可能是客户机内编码错误的结果。因此，包含这两个首选项的请求可以被视为两个首选项都没有指定。
The "wait" preference can be used to establish an upper bound on the length of time, in seconds, the client expects it will take the server to process the request once it has been received. In the case that generating a response will take longer than the time specified, the server, or proxy, can choose to utilize an asynchronous processing model by returning -- for example -- a 202 (Accepted) response.
“wait”首选项可用于确定时间长度的上限，以秒为单位，客户机希望服务器在收到请求后处理该请求。在生成响应所需时间超过指定时间的情况下，服务器或代理可以通过返回（例如）202（已接受）响应来选择使用异步处理模型。
ABNF:
荷兰银行：
wait = "wait" BWS "=" BWS delta-seconds
wait=“wait”BWS“=“BWS增量秒
It is important to consider that HTTP messages spend some time traversing the network and being processed by intermediaries. This increases the length of time that a client will wait for a response in addition to the time the server takes to process the request. A client that has strict timing requirements can estimate these factors and adjust the wait value accordingly.
重要的是要考虑HTTP消息花一些时间遍历网络并由中间人处理。这增加了客户端等待响应的时间长度以及服务器处理请求所需的时间。具有严格定时要求的客户机可以估计这些因素并相应地调整等待值。
As with other preferences, the "wait" preference could be ignored. Clients can abandon requests that take longer than they are prepared to wait.
与其他首选项一样，“等待”首选项可以忽略。客户端可以放弃比他们准备等待的时间更长的请求。
For example, a server receiving the following request might choose to respond asynchronously if processing the request will take longer than 10 seconds:
例如，如果处理请求的时间超过10秒，则接收以下请求的服务器可能会选择异步响应：
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async, wait=10
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: respond-async, wait=10
{Data}
{Data}
4.4. The "handling=strict" and "handling=lenient" Processing Preferences
4.4. “处理=严格”和“处理=宽松”处理首选项
The "handling=strict" and "handling=lenient" preferences indicate, at the server's discretion, how the client wishes the server to handle potential error conditions that can arise in the processing of a request. For instance, if the payload of a request contains various minor syntactical or semantic errors, but the server is still capable of comprehending and successfully processing the request, a decision must be made to either reject the request with an appropriate "4xx" error response or go ahead with processing. The "handling=strict" preference can be used to indicate that, while any particular error may be recoverable, the client would prefer that the server reject the request. The "handling=lenient" preference, on the other hand, indicates that the client wishes the server to attempt to process the request.
“handling=strict”和“handling=lenient”首选项由服务器自行决定，指示客户端希望服务器如何处理处理请求处理过程中可能出现的潜在错误情况。例如，如果请求的有效负载包含各种较小的语法或语义错误，但服务器仍然能够理解并成功处理该请求，则必须做出决定，要么拒绝带有适当“4xx”错误响应的请求，要么继续处理。“handling=strict”首选项可用于指示，尽管任何特定错误都可以恢复，但客户端希望服务器拒绝该请求。另一方面，“handling=lenient”首选项表示客户端希望服务器尝试处理请求。
ABNF:
荷兰银行：
handling = "handling" BWS "=" BWS ("strict" / "lenient")
handling = "handling" BWS "=" BWS ("strict" / "lenient")
An example request specifying the "strict" preference:
指定“严格”首选项的请求示例：
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: handling=strict
POST /collection HTTP/1.1
Host: example.org
Content-Type: text/plain
Prefer: handling=strict
The "handling=strict" and "handling=lenient" preferences are mutually exclusive directives. It is anticipated that there will never be a situation where it will make sense for a single request to include both preferences. Any such requests will likely be the result of a coding error within the client. As such, a request containing both preferences can be treated as though neither were specified.
“handling=strict”和“handling=lencient”首选项是相互排斥的指令。可以预见，在任何情况下，一个请求包含两个首选项都是有意义的。任何此类请求都可能是客户机内编码错误的结果。因此，包含这两个首选项的请求可以被视为两个首选项都没有指定。
The 'Prefer' and 'Preference-Applied' header fields have been added to the "Permanent Message Header Field Names" registry defined in [RFC3864] (http://www.iana.org/assignments/message-headers).
“首选项”和“应用首选项”标题字段已添加到[RFC3864]中定义的“永久消息标题字段名称”注册表中(http://www.iana.org/assignments/message-headers).
Header field name: Prefer
标题字段名称：首选
Applicable Protocol: HTTP
适用协议：HTTP
Status: Standard
状态：标准
Author: James M Snell <jasnell@gmail.com>
Author: James M Snell <jasnell@gmail.com>
Change controller: IETF
更改控制器：IETF
Specification document: this specification, Section 2
规范文件：本规范第2节
Header field name: Preference-Applied
标题字段名称：已应用首选项
Applicable Protocol: HTTP
适用协议：HTTP
Status: Standard
状态：标准
Author: James M Snell <jasnell@gmail.com>
Author: James M Snell <jasnell@gmail.com>
Change controller: IETF
更改控制器：IETF
Specification document: this specification, Section 3
规范文件：本规范第3节
IANA has created a new registry, "HTTP Preferences", under the "Hypertext Transfer Protocol (HTTP) Parameters" registry. New registrations will use the Specification Required policy [RFC5226]. The requirements for registered preferences are described in Section 4.
IANA在“超文本传输协议（HTTP）参数”注册表下创建了一个新的注册表“HTTP首选项”。新注册将使用规范要求的策略[RFC5226]。第4节描述了注册偏好的要求。
Registration requests consist of the completed registration template below, typically published in the required specification. However, to allow for the allocation of values prior to publication, the Designated Expert can approve registration based on a separately submitted template once they are satisfied that a specification will be published. Preferences can be registered by third parties if the Designated Expert determines that an unregistered preference is widely deployed and not likely to be registered in a timely manner.
注册请求包括以下已完成的注册模板，通常以要求的规范发布。但是，为了允许在发布之前分配值，指定专家可以在满足规范发布要求后，根据单独提交的模板批准注册。如果指定专家确定未注册的首选项已广泛部署且不可能及时注册，则第三方可以注册首选项。
The registration template is:
注册模板为：
o Preference: (A value for the Prefer request header field that conforms to the syntax rule given in Section 2)
o 首选项：（符合第2节给出的语法规则的首选请求头字段的值）
o Value: (An enumeration or description of possible values for the preference token).
o 值：（首选项标记的可能值的枚举或描述）。
o Optional Parameters: (An enumeration of optional parameters, and their values, associated with the preference token).
o 可选参数：（可选参数及其值的枚举，与首选项标记关联）。
o Description:
o 说明：
o Reference:
o 参考：
o Notes: [optional]
o 注：[可选]
The "Value" and "Optional Parameters" fields MAY be omitted from the registration template if the specific preference token definition does not define either.
如果特定的首选项令牌定义未定义“值”和“可选参数”字段，则可以从注册模板中省略这些字段。
Registration requests should be sent to the <ietf-http-wg@w3.org> mailing list, marked clearly in the subject line (e.g., "NEW PREFERENCE - example" to register an "example" preference). Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
注册请求应发送至<ietf http-wg@w3.org>邮件列表，在主题行中清楚标记（例如，“新偏好-示例”以注册“示例”偏好）。在申请后最多14天内，指定专家将批准或拒绝注册申请，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
The Expert Reviewer shall ensure:
专家审评员应确保：
o That the requested preference name conforms to the token rule in Section 2 and that it is not identical to any other registered preference name;
o 请求的首选项名称符合第2节中的令牌规则，并且与任何其他注册的首选项名称不相同；
o That any associated value, parameter names, and values conform to the relevant ABNF grammar specifications in Section 2;
o 任何相关值、参数名称和值符合第2节中的相关ABNF语法规范；
o That the name is appropriate to the specificity of the preference; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names remain available for less specific uses.
o 名称与偏好的特殊性相适应；i、 例如，如果语义非常特定于特定应用程序，则名称应反映这一点，以便更通用的名称可用于不太特定的用途。
o That requested preferences do not constrain servers, clients, or any intermediaries to any behavior required for successful processing; and
o 请求的首选项不会将服务器、客户机或任何中介限制为成功处理所需的任何行为；和
o That the specification document defining the preference includes a proper and complete discussion of any security considerations relevant to the use of the preference.
o 定义首选项的规范文件包括与使用首选项相关的任何安全考虑的适当和完整的讨论。
The "HTTP Preferences" registry's initial contents are:
“HTTP首选项”注册表的初始内容是：
o Preference: respond-async
o 首选项：异步响应
o Description: Indicates that the client prefers that the server respond asynchronously to a request.
o 描述：表示客户端希望服务器异步响应请求。
o Reference: [this specification], Section 4.1
o 参考：[本规范]，第4.1节
o Preference: return
o 偏好：返回
o Value: One of either "minimal" or "representation"
o 值：“最小”或“表示”之一
o Description: When the value is "minimal", it indicates that the client prefers that the server return a minimal response to a request. When the value is "representation", it indicates that the client prefers that the server include a representation of the current state of the resource in response to a request.
o 描述：当值为“minimal”时，表示客户端希望服务器对请求返回最小响应。当该值为“representation”时，表示客户端希望服务器在响应请求时包含资源当前状态的表示。
o Reference: [this specification], Section 4.2
o 参考：[本规范]，第4.2节
o Preference: wait
o 偏好：等等
o Description: Indicates an upper bound to the length of time the client expects it will take for the server to process the request once it has been received.
o Description：表示客户端希望服务器在收到请求后处理该请求所需的时间长度上限。
o Reference: [this specification], Section 4.3
o 参考：[本规范]，第4.3节
o Preference: handling
o 偏好：处理
o Value: One of either "strict" or "lenient"
o 值：“严格”或“宽松”之一
o Description: When value is "strict", it indicates that the client wishes the server to apply strict validation and error handling to the processing of a request. When the value is "lenient", it indicates that the client wishes the server to apply lenient validation and error handling to the processing of the request.
o 描述：当值为“strict”时，表示客户端希望服务器对请求的处理应用严格的验证和错误处理。当该值为“lenient”时，表示客户端希望服务器对请求的处理应用lenient验证和错误处理。
o Reference: [this specification], Section 4.4
o 参考：[本规范]，第4.4节
Specific preferences requested by a client can introduce security considerations and concerns beyond those discussed within HTTP/1.1 [RFC7230] and its associated specification documents (see [RFC7230] for the list of associated works). Implementers need to refer to the specifications and descriptions of each preference to determine the security considerations relevant to each.
客户机请求的特定首选项可能会引入HTTP/1.1[RFC7230]及其相关规范文档中讨论的安全注意事项和问题（相关工作列表请参见[RFC7230]）。实现者需要参考每个首选项的规范和描述，以确定与每个首选项相关的安全注意事项。
A server could incur greater costs in attempting to comply with a particular preference (for instance, the cost of providing a representation in a response that would not ordinarily contain one; or the commitment of resources necessary to track state for an asynchronous response). Unconditional compliance from a server could allow the use of preferences for denial of service. A server can ignore an expressed preference to avoid expending resources that it does not wish to commit.
服务器在尝试遵从特定首选项时可能会产生更大的成本（例如，在响应中提供通常不包含的表示的成本；或跟踪异步响应状态所需的资源投入）。来自服务器的无条件遵从可能允许使用首选项拒绝服务。服务器可以忽略已表达的首选项，以避免消耗它不希望提交的资源。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023]Gregorio，J.和B.de hOra，“原子发布协议”，RFC 5023，2007年10月。
Author's Address
作者地址
James M Snell
詹姆斯·姆斯内尔
EMail: jasnell@gmail.com
EMail: jasnell@gmail.com