Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7232 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Category: Standards Track greenbytes
ISSN: 2070-1721 June 2014
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7232 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Category: Standards Track greenbytes
ISSN: 2070-1721 June 2014
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
超文本传输协议（HTTP/1.1）：条件请求
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.
超文本传输协议（HTTP）是用于分布式、协作式超文本信息系统的无状态应用程序级协议。本文档定义了HTTP/1.1条件请求，包括用于指示状态更改的元数据头字段、用于对此类状态设置前提条件的请求头字段，以及用于在一个或多个前提条件计算为false时构造对条件请求的响应的规则。
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/rfc7232.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7232.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
2. Validators ......................................................5
2.1. Weak versus Strong .........................................5
2.2. Last-Modified ..............................................7
2.2.1. Generation ..........................................7
2.2.2. Comparison ..........................................8
2.3. ETag .......................................................9
2.3.1. Generation .........................................10
2.3.2. Comparison .........................................10
2.3.3. Example: Entity-Tags Varying on
Content-Negotiated Resources .......................11
2.4. When to Use Entity-Tags and Last-Modified Dates ...........12
3. Precondition Header Fields .....................................13
3.1. If-Match ..................................................13
3.2. If-None-Match .............................................14
3.3. If-Modified-Since .........................................16
3.4. If-Unmodified-Since .......................................17
3.5. If-Range ..................................................18
4. Status Code Definitions ........................................18
4.1. 304 Not Modified ..........................................18
4.2. 412 Precondition Failed ...................................19
5. Evaluation .....................................................19
6. Precedence .....................................................20
7. IANA Considerations ............................................22
7.1. Status Code Registration ..................................22
7.2. Header Field Registration .................................22
8. Security Considerations ........................................22
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Changes from RFC 2616 .................................25
Appendix B. Imported ABNF .........................................25
Appendix C. Collected ABNF ........................................26
Index .............................................................27
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
2. Validators ......................................................5
2.1. Weak versus Strong .........................................5
2.2. Last-Modified ..............................................7
2.2.1. Generation ..........................................7
2.2.2. Comparison ..........................................8
2.3. ETag .......................................................9
2.3.1. Generation .........................................10
2.3.2. Comparison .........................................10
2.3.3. Example: Entity-Tags Varying on
Content-Negotiated Resources .......................11
2.4. When to Use Entity-Tags and Last-Modified Dates ...........12
3. Precondition Header Fields .....................................13
3.1. If-Match ..................................................13
3.2. If-None-Match .............................................14
3.3. If-Modified-Since .........................................16
3.4. If-Unmodified-Since .......................................17
3.5. If-Range ..................................................18
4. Status Code Definitions ........................................18
4.1. 304 Not Modified ..........................................18
4.2. 412 Precondition Failed ...................................19
5. Evaluation .....................................................19
6. Precedence .....................................................20
7. IANA Considerations ............................................22
7.1. Status Code Registration ..................................22
7.2. Header Field Registration .................................22
8. Security Considerations ........................................22
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Changes from RFC 2616 .................................25
Appendix B. Imported ABNF .........................................25
Appendix C. Collected ABNF ........................................26
Index .............................................................27
Conditional requests are HTTP requests [RFC7231] that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in [RFC7230].
条件请求是HTTP请求[RFC7231]，其中包括一个或多个头字段，指示在将方法语义应用于目标资源之前要测试的先决条件。本文档根据[RFC7230]中定义的体系结构、语法符号和一致性标准定义了HTTP/1.1条件请求机制。
Conditional GET requests are the most efficient mechanism for HTTP cache updates [RFC7234]. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.
条件GET请求是HTTP缓存更新最有效的机制[RFC7234]。条件也可以应用于状态更改方法，如PUT和DELETE，以防止“丢失更新”问题：一个客户端意外地覆盖了另一个并行运行的客户端的工作。
Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (Section 3 of [RFC7231]) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.
条件请求先决条件基于目标资源作为一个整体的状态（其当前值集）或在先前获得的表示中观察到的状态（该集合中的一个值）。一个资源可能有多个当前表示，每个表示都有自己的可观察状态。条件请求机制假设，如果服务器打算利用条件，则请求到“选定表示”（RFC7231）的映射（第3节）将随着时间的推移保持一致。无论如何，如果映射不一致且服务器无法选择适当的表示形式，则前提条件的计算结果为false时不会造成任何损害。
The conditional request preconditions defined by this specification (Section 3) are evaluated when applicable to the recipient (Section 5) according to their order of precedence (Section 6).
本规范（第3节）定义的条件请求先决条件在适用于接收方（第5节）时，根据其优先顺序（第6节）进行评估。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
[RFC7230]第2.5节定义了与错误处理相关的一致性标准和注意事项。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates
本规范使用[RFC7230]第7节中定义的带列表扩展的[RFC5234]增广巴科斯诺尔形式（ABNF）表示法，允许使用“#”运算符（类似于“*”运算符指示的方式）对逗号分隔的列表进行紧凑定义
repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.
重复）。附录B描述了从其他文件导入的规则。附录C显示了收集的语法，所有列表运算符都扩展为标准ABNF表示法。
This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (Section 2.2) and opaque entity tags (Section 2.3). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the scope of this specification. A resource metadata value is referred to as a "validator" when it is used within a precondition.
本规范定义了两种元数据形式，通常用于观察资源状态和测试前提条件：修改日期（第2.2节）和不透明实体标记（第2.3节）。HTTP的各种扩展定义了反映资源状态的其他元数据，例如Web分布式创作和版本控制（WebDAV，[RFC4918]），这些扩展超出了本规范的范围。资源元数据值在前提条件内使用时称为“验证器”。
Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.
验证器有两种类型：强验证器和弱验证器。弱验证器很容易生成，但对于比较来说用处要小得多。强验证器非常适合进行比较，但要高效地生成它可能非常困难（有时甚至不可能）。HTTP公开了正在使用的验证器的类型，并对弱验证器何时可用作先决条件进行了限制，而不是强制要求所有形式的资源都遵循相同的验证器强度。
A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a 200 (OK) response to GET.
“强验证器”是一种表示元数据，每当表示数据发生变化时，表示元数据的值就会发生变化，而这种变化在要获取的200（OK）响应的有效负载主体中是可以观察到的。
A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.
强验证器可能会因为表示数据更改以外的原因而更改，例如当表示元数据的语义重要部分发生更改时（例如，内容类型），但是，只有在需要使远程缓存和创作工具保存的存储响应无效时，才更改值才符合源服务器的最佳利益。
Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).
缓存项可能会持续任意长的时间，而与过期时间无关。因此，缓存可能会尝试使用它在遥远的过去获得的验证器来验证条目。随着时间的推移，强验证器在与特定资源关联的所有表示的所有版本中都是唯一的。但是，不同资源的表示之间不存在唯一性的含义（即，同一个强验证器可能同时用于多个资源的表示，并不意味着这些表示是等效的）。
There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.
在实践中使用了各种各样的强验证器。最好的方法是基于严格的版本控制，其中对表示的每次更改都会导致在访问表示之前分配唯一的节点名称和版本标识符。如果在发送响应头字段之前数据可用，并且不需要在每次收到验证请求时重新计算摘要，那么应用于表示数据的抗冲突哈希函数也就足够了。但是，如果资源具有仅在元数据上不同的不同表示形式，例如可能会发生在共享相同数据格式的媒体类型上的内容协商，则源服务器需要在验证器中包含其他信息以区分这些表示形式。
In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server SHOULD change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
相反，“弱验证器”是表示元数据，可能不会因表示数据的每次更改而更改。这一弱点可能是由于计算值的方式受到限制，例如时钟分辨率，无法确保资源所有可能表示的唯一性，或者资源所有者希望通过某种自行确定的等价集而不是唯一的数据序列来对表示进行分组。当源服务器认为以前的表示不能替代当前表示时，它应该更改弱实体标记。换句话说，只要源服务器希望缓存使旧响应无效，弱实体标记就应该更改。
For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.
例如，基于动态测量值，每秒内容发生变化的天气报告的表示形式可以使用相同的弱验证器分组为一组等效表示形式（从源服务器的角度来看），以便允许缓存的表示形式在合理的时间段内有效（可能会根据服务器负载或天气质量进行动态调整）。同样，如果表示的修改时间仅定义为1秒分辨率，则表示的修改时间可能是弱验证器，前提是表示可以在一秒钟内修改两次，并在这些修改之间检索。
Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.
同样，如果验证器同时由给定资源的两个或多个表示共享，则验证器是弱的，除非这些表示具有相同的表示数据。例如，如果源服务器为应用了gzip内容编码的表示发送相同的验证器，就像对没有内容编码的表示发送相同的验证器一样，那么该验证器是弱的。但是，如果两个同时表示仅在表示元数据上不同，例如当两种不同的媒体类型可用于相同的表示数据时，则它们可能共享同一个强验证器。
Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.
强验证器可用于所有条件请求，包括缓存验证、部分内容范围和“丢失更新”避免。弱验证器仅在客户端不需要与以前获得的表示数据完全相等时可用，例如在验证缓存项或将web遍历限制为最近的更改时。
The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.
响应中的“Last Modified”标头字段提供了一个时间戳，指示源服务器认为所选表示是最后一次修改的日期和时间，如处理请求的结论所确定的。
Last-Modified = HTTP-date
Last-Modified = HTTP-date
An example of its use is
其使用的一个例子是
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness ([RFC7234]) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability.
源服务器应该为任何选定的表示发送Last Modified（最后修改日期可以合理一致地确定），因为它用于条件请求和评估缓存新鲜度（[RFC7234]）结果大大减少了Internet上的HTTP流量，并且可以成为提高服务可扩展性和可靠性的一个重要因素。
A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can use its value to make conditional requests and test the validity of locally cached responses.
表示通常是资源接口后面的许多部分的总和。最后一次修改的时间通常是这些部件中任何一个发生更改的最近时间。如何为任何给定资源确定该值是本规范范围之外的实现细节。对HTTP来说，重要的是最后修改的头字段的接收者如何使用其值来发出条件请求和测试本地缓存响应的有效性。
An origin server SHOULD obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field value for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially if the representation changes near the time that the response is generated.
源服务器应在尽可能接近为其响应生成日期字段值的时间获取表示形式的最后修改值。这允许接收者对表示的修改时间进行准确的评估，特别是当表示在生成响应的时间附近发生变化时。
An origin server with a clock MUST NOT send a Last-Modified date that is later than the server's time of message origination (Date). If the last modification time is derived from implementation-specific
带有时钟的源服务器发送的上次修改日期不得晚于服务器的邮件发起时间（日期）。如果上次修改时间是从特定于实现的
metadata that evaluates to some time in the future, according to the origin server's clock, then the origin server MUST replace that value with the message origination date. This prevents a future modification date from having an adverse impact on cache validation.
根据源服务器的时钟，计算为未来某个时间的元数据，则源服务器必须用消息起始日期替换该值。这可以防止将来的修改日期对缓存验证产生不利影响。
An origin server without a clock MUST NOT assign Last-Modified values to a response unless these values were associated with the resource by some other system or user with a reliable clock.
没有时钟的源服务器不得将上次修改的值分配给响应，除非这些值由具有可靠时钟的其他系统或用户与资源关联。
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
当在请求中用作验证器时，上一次修改的时间隐式弱，除非可以使用以下规则推断它是强的：
o The validator is being compared by an origin server to the actual current validator for the representation and,
o 源服务器正在将验证程序与表示的实际当前验证程序进行比较，
o That origin server reliably knows that the associated representation did not change twice during the second covered by the presented validator.
o 该源服务器可靠地知道，关联的表示在所提供的验证器覆盖的第二个过程中没有两次更改。
or
或
o The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since, or If-Range header field, because the client has a cache entry for the associated representation, and
o 验证程序将由客户端在If-Modified-Since、If-Unmodified-Since或If-Range头字段中使用，因为客户端具有关联表示的缓存项，并且
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 显示的上次修改时间至少比日期值早60秒。
or
或
o The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and
o 中间缓存正在将验证器与存储在其表示的缓存项中的验证器进行比较，以及
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 显示的上次修改时间至少比日期值早60秒。
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
此方法依赖于这样一个事实：如果源服务器在同一秒钟内发送了两个不同的响应，但都具有相同的上次修改时间，则这些响应中至少有一个的日期值等于其上次修改的时间。任意的60秒限制可以防止日期和最后修改的值是在响应准备期间从不同的时钟或在稍微不同的时间生成的。如果认为60秒太短，则实现可以使用大于60秒的值。
The "ETag" header field in a response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
响应中的“ETag”头字段为所选表示提供当前实体标记，如处理请求结束时确定的。实体标记是一个不透明的验证器，用于区分同一资源的多个表示，而不管这些多个表示是由于资源状态随时间的变化、导致多个表示同时有效的内容协商，还是两者兼而有之。实体标记由不透明的带引号的字符串组成，可能以弱点指示符作为前缀。
ETag = entity-tag
ETag = entity-tag
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
Note: Previously, opaque-tag was defined to be a quoted-string ([RFC2616], Section 3.11); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity tags.
注：之前，不透明标签定义为带引号的字符串（[RFC2616]，第3.11节）；因此，某些收件人可能会执行反斜杠取消跳过。因此，服务器应该避免在实体标记中使用反斜杠字符。
An entity-tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where modification dates are not consistently maintained.
在不方便存储修改日期、HTTP日期值的1秒分辨率不够或修改日期未得到一致维护的情况下，实体标记的验证可能比修改日期更可靠。
Examples:
示例：
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
ETag:“xyzy”ETag:W/“xyzy”ETag:“
An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag for a representation and the generation of that entity-tag does not satisfy all of the characteristics of a strong validator (Section 2.1), then the origin server MUST mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive).
实体标记可以是弱验证器，也可以是强验证器，默认为强验证器。如果源服务器为表示提供实体标记，并且该实体标记的生成不满足强验证器的所有特征（第2.1节），则源服务器必须通过在其不透明值前加上“W/（区分大小写）将该实体标记标记为弱。
The principle behind entity-tags is that only the service author knows the implementation of a resource well enough to select the most accurate and efficient validation mechanism for that resource, and that any such mechanism can be mapped to a simple sequence of octets for easy comparison. Since the value is opaque, there is no need for the client to be aware of how each entity-tag is constructed.
实体标记背后的原理是，只有服务作者对资源的实现有足够的了解，能够为该资源选择最准确、最有效的验证机制，并且任何此类机制都可以映射到一个简单的八位字节序列，以便于比较。由于该值是不透明的，因此客户端不需要知道每个实体标记是如何构造的。
For example, a resource that has implementation-specific versioning applied to all changes might use an internal revision number, perhaps combined with a variance identifier for content negotiation, to accurately differentiate between representations. Other implementations might use a collision-resistant hash of representation content, a combination of various file attributes, or a modification timestamp that has sub-second resolution.
例如，将特定于实现的版本控制应用于所有更改的资源可能会使用内部版本号，可能与用于内容协商的差异标识符相结合，以准确区分表示。其他实现可能使用表示内容的抗冲突散列、各种文件属性的组合或具有亚秒分辨率的修改时间戳。
An origin server SHOULD send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since the entity-tag's use in conditional requests and evaluating cache freshness ([RFC7234]) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability and reliability.
由于实体标记用于条件请求和评估缓存新鲜度（[RFC7234]），因此源服务器应为任何选定的表示形式发送ETag，以便合理且一致地确定对其进行的更改检测可以大大减少HTTP网络流量，并且是提高服务可伸缩性和可靠性的一个重要因素。
There are two entity-tag comparison functions, depending on whether or not the comparison context allows the use of weak validators:
根据比较上下文是否允许使用弱验证器，有两个实体标记比较函数：
o Strong comparison: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
o 强比较：如果两个实体标记不是弱的，并且它们的不透明标记逐字符匹配，则两个实体标记是等效的。
o Weak comparison: two entity-tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged as "weak".
o 弱比较：如果两个实体标记的不透明标记逐字符匹配，则两个实体标记是等效的，而不管其中一个或两个标记为“弱”。
The example below shows the results for a set of entity-tag pairs and both the weak and strong comparison function results:
下面的示例显示了一组实体标记对的结果以及弱比较函数和强比较函数的结果：
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
Consider a resource that is subject to content negotiation (Section 3.4 of [RFC7231]), and where the representations sent in response to a GET request vary based on the Accept-Encoding request header field (Section 5.3.4 of [RFC7231]):
考虑受内容协商的资源（[RCF7241]的第3.4节），其中响应于GET请求发送的表示基于接受编码请求头字段（[RC7711]的第5.3.4节）而变化：
>> Request:
>>请求：
GET /index HTTP/1.1 Host: www.example.com Accept-Encoding: gzip
GET/index HTTP/1.1主机：www.example.com接受编码：gzip
In this case, the response might or might not use the gzip content coding. If it does not, the response might look like:
在这种情况下，响应可能使用gzip内容编码，也可能不使用。如果没有，则响应可能如下所示：
>> Response:
>>答复：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! Hello World! Hello World! Hello World! Hello World!
你好，世界！你好，世界！你好，世界！你好，世界！你好，世界！
An alternative representation that does use gzip content coding would be:
使用gzip内容编码的另一种表示形式是：
>> Response:
>>答复：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip
...binary data...
…二进制数据。。。
Note: Content codings are a property of the representation data, so a strong entity-tag for a content-encoded representation has to be distinct from the entity tag of an unencoded representation to prevent potential conflicts during cache updates and range requests. In contrast, transfer codings (Section 4 of [RFC7230]) apply only during message transfer and do not result in distinct entity-tags.
注意：内容编码是表示数据的属性，因此内容编码表示的强实体标记必须与未编码表示的实体标记不同，以防止在缓存更新和范围请求期间发生潜在冲突。相反，传输编码（RFC7230第4节）仅在消息传输期间适用，不会产生不同的实体标记。
In 200 (OK) responses to GET or HEAD, an origin server:
在GET或HEAD的200（确定）响应中，源服务器：
o SHOULD send an entity-tag validator unless it is not feasible to generate one.
o 应发送实体标记验证程序，除非生成实体标记验证程序不可行。
o MAY send a weak entity-tag instead of a strong entity-tag, if performance considerations support the use of weak entity-tags, or if it is unfeasible to send a strong entity-tag.
o 如果性能考虑支持使用弱实体标记，或者如果无法发送强实体标记，则可以发送弱实体标记而不是强实体标记。
o SHOULD send a Last-Modified value if it is feasible to send one.
o 如果发送一个值是可行的，则应发送最后修改的值。
In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a Last-Modified value in successful responses to a retrieval request.
换句话说，源服务器的首选行为是在成功响应检索请求时发送强实体标记和最后修改的值。
A client:
客户：
o MUST send that entity-tag in any cache validation request (using If-Match or If-None-Match) if an entity-tag has been provided by the origin server.
o 如果源服务器提供了实体标记，则必须在任何缓存验证请求中发送该实体标记（使用If-Match或If-None-Match）。
o SHOULD send the Last-Modified value in non-subrange cache validation requests (using If-Modified-Since) if only a Last-Modified value has been provided by the origin server.
o 如果源服务器仅提供了上次修改的值，则应在非子范围缓存验证请求中发送上次修改的值（使用If Modified Since）。
o MAY send the Last-Modified value in subrange cache validation requests (using If-Unmodified-Since) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent SHOULD provide a way to disable this, in case of difficulty.
o 如果HTTP/1.0源服务器仅提供了上次修改的值，则可以在子范围缓存验证请求中发送上次修改的值（如果未修改，则使用）。如果遇到困难，用户代理应该提供一种禁用此功能的方法。
o SHOULD send both validators in cache validation requests if both an entity-tag and a Last-Modified value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
o 如果源服务器提供了实体标记和上次修改的值，则应在缓存中发送两个验证器验证请求。这使得HTTP/1.0和HTTP/1.1缓存都能做出适当的响应。
This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. Section 5 defines when the preconditions are applied. Section 6 defines the order of evaluation when more than one precondition is present.
本节定义了HTTP/1.1头字段的语法和语义，用于对请求应用前提条件。第5节定义了应用前提条件的时间。第6节定义了存在多个先决条件时的评估顺序。
The "If-Match" header field makes the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is "*", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value.
当字段值为“*”时，“If Match”标头字段使请求方法以收件人源服务器至少具有目标资源的一个当前表示形式为条件，或者具有目标资源的当前表示，该目标资源具有与字段值中提供的实体标记列表的成员匹配的实体标记。
An origin server MUST use the strong comparison function when comparing entity-tags for If-Match (Section 2.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.
当比较If Match的实体标记时，源服务器必须使用强比较功能（第2.3.2节），因为客户端打算在表示数据发生任何更改时使用此先决条件来防止应用该方法。
If-Match = "*" / 1#entity-tag
If-Match = "*" / 1#entity-tag
Examples:
示例：
If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: *
如果匹配：“XYZY”如果匹配：“XYZY”、“r2d2xxxx”、“c3piozzzz”如果匹配：*
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to
如果Match最常用于状态更改方法（例如POST、PUT、DELETE），以防止在多个用户代理可能并行操作同一资源（即
prevent the "lost update" problem). It can also be used with safe methods to abort a request if the selected representation does not match one already stored (or partially stored) from a prior request.
防止“丢失更新”问题）。如果选定的表示形式与先前请求中已存储（或部分存储）的表示形式不匹配，则它还可以与安全方法一起用于中止请求。
An origin server that receives an If-Match header field MUST evaluate the condition prior to performing the method (Section 5). If the field-value is "*", the condition is false if the origin server does not have a current representation for the target resource. If the field-value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation.
接收If Match头字段的源服务器必须在执行该方法之前评估条件（第5节）。如果字段值为“*”，则如果源服务器没有目标资源的当前表示形式，则条件为false。如果字段值是实体标记列表，则如果列出的标记中没有一个与选定表达的实体标记匹配，则条件为false。
An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent). In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
如果接收到的if匹配条件评估为false，则源服务器不得执行请求的方法；相反，如果源服务器已验证正在请求状态更改，且最终状态已反映在目标资源的当前状态中，则源服务器必须使用a）412（前提条件失败）状态代码或b）2xx（成功）状态代码之一进行响应（即，用户代理请求的更改已经成功，但用户代理可能没有意识到，这可能是因为先前的响应丢失或某个其他用户代理进行了兼容更改）。在后一种情况下，源服务器不得在响应中发送validator标头字段，除非它可以验证该请求是否与同一用户代理之前所做的更改重复。
The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
缓存和中介可以忽略If Match header字段，因为它不适用于存储的响应。
The "If-None-Match" header field makes the request method conditional on a recipient cache or origin server either not having any current representation of the target resource, when the field-value is "*", or having a selected representation with an entity-tag that does not match any of those listed in the field-value.
“If None Match”（如果不匹配）标头字段使请求方法以收件人缓存或源服务器为条件，当字段值为“*”时，该服务器没有目标资源的任何当前表示形式，或者具有与字段值中列出的任何表示形式不匹配的实体标记的选定表示形式。
A recipient MUST use the weak comparison function when comparing entity-tags for If-None-Match (Section 2.3.2), since weak entity-tags can be used for cache validation even if there have been changes to the representation data.
收件人在比较实体标记是否不匹配时必须使用弱比较功能（第2.3.2节），因为弱实体标记可用于缓存验证，即使表示数据发生了更改。
If-None-Match = "*" / 1#entity-tag
If-None-Match = "*" / 1#entity-tag
Examples:
示例：
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity-tags, the client SHOULD generate an If-None-Match header field containing a list of those entity-tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.
如果“无匹配”主要用于条件GET请求，则可以以最小的事务开销高效地更新缓存信息。当客户机希望更新一个或多个具有实体标记的存储响应时，客户机应在发出GET请求时生成包含这些实体标记列表的If None Match头字段；这允许收件人服务器发送304（未修改）响应，以指示其中一个存储的响应何时与所选表示匹配。
If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation (Section 4.2.1 of [RFC7231]). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation for the target resource.
如果“无匹配”也可以与值“*”一起使用，以防止不安全的请求方法（如PUT）在客户端认为目标资源没有当前表示时无意中修改该资源的现有表示（RFC7231的第4.2.1节）。这是“丢失更新”问题的变体，如果多个客户端尝试为目标资源创建初始表示，则可能会出现该问题。
An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (Section 5). If the field-value is "*", the condition is false if the origin server has a current representation for the target resource. If the field-value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the selected representation.
接收“如果不匹配”标头字段的源服务器必须在执行该方法之前评估条件（第5节）。如果字段值为“*”，则如果源服务器具有目标资源的当前表示形式，则条件为false。如果字段值是实体标记列表，则如果列出的标记之一与选定表达的实体标记匹配，则条件为false。
An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the 304 (Not Modified) status code if the request method is GET or HEAD or b) the 412 (Precondition Failed) status code for all other request methods.
如果条件评估为false，则源服务器不得执行请求的方法；相反，原始服务器必须响应a）如果请求方法为GET或HEAD，则为304（未修改）状态代码，或者b）所有其他请求方法的412（前提条件失败）状态代码。
Requirements on cache handling of a received If-None-Match header field are defined in Section 4.3.2 of [RFC7234].
[RFC7234]第4.3.2节定义了接收到的如果不匹配头字段的缓存处理要求。
The "If-Modified-Since" header field makes a GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field-value. Transfer of the selected representation's data is avoided if that data has not changed.
“If Modified Since”标头字段使GET或HEAD请求方法以所选表示的修改日期比字段值中提供的日期更晚为条件。如果选定表达的数据未更改，则可以避免传输该数据。
If-Modified-Since = HTTP-date
If-Modified-Since = HTTP-date
An example of the field is:
该字段的一个示例是：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.
如果修改，收件人必须忽略，因为如果请求包含If None匹配头字段；If None Match中的条件被认为是If Modified中的条件的更准确替代，因为这两个条件的结合只是为了与旧的中介体进行互操作，而旧的中介体在If None Match中可能无法实现。
A recipient MUST ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is neither GET nor HEAD.
如果收到的字段值不是有效的HTTP日期，或者如果请求方法既不是GET也不是HEAD，则收件人必须忽略If Modified Since标头字段。
A recipient MUST interpret an If-Modified-Since field-value's timestamp in terms of the origin server's clock.
收件人必须根据源服务器的时钟解释If Modified-Since字段值的时间戳。
If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.
If-Modified-Since通常用于两个不同的目的：1）允许对没有实体标记的缓存表示进行有效更新；2）将web遍历的范围限制为最近更改的资源。
When used for cache updates, a cache will typically use the value of the cached message's Last-Modified field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived backup). However, caches occasionally generate the field value based on other data, such as the Date header field of the cached message or the local clock time that the message was received, particularly when the cached message does not contain a Last-Modified field.
当用于缓存更新时，缓存通常会使用缓存消息上次修改字段的值来生成If Modified Since的字段值。在时钟同步不良或服务器选择只执行精确的时间戳匹配的情况下（由于上次修改的日期出现问题，当源服务器的时钟被更正或从存档备份还原表示时，这些日期似乎“回到时间”）此行为最具互操作性。但是，缓存偶尔会基于其他数据生成字段值，例如缓存消息的日期标头字段或接收消息的本地时钟时间，特别是当缓存消息不包含上次修改的字段时。
When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field value based on either its own local clock or a Date header field received from the server in a prior response. Origin servers that choose an exact timestamp match based on the selected representation's Last-Modified field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
当用于将检索范围限制到最近的时间窗口时，用户代理将根据其自己的本地时钟或先前响应中从服务器接收的日期头字段生成“如果修改自”字段值。基于选定表示的上次修改字段选择精确时间戳匹配的源服务器将无法帮助用户代理将其数据传输限制为仅在指定窗口期间更改的数据传输。
An origin server that receives an If-Modified-Since header field SHOULD evaluate the condition prior to performing the method (Section 5). The origin server SHOULD NOT perform the requested method if the selected representation's last modification date is earlier than or equal to the date provided in the field-value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response.
接收If-Modified-Since标头字段的源服务器应在执行该方法之前评估条件（第5节）。如果所选表示的上次修改日期早于或等于字段值中提供的日期，则源服务器不应执行请求的方法；相反，源服务器应该生成304（未修改）响应，只包括那些用于识别或更新先前缓存的响应的元数据。
Requirements on cache handling of a received If-Modified-Since header field are defined in Section 4.3.2 of [RFC7234].
[RFC7234]第4.3.2节中定义了接收到的（如果修改了）头字段的缓存处理要求。
The "If-Unmodified-Since" header field makes the request method conditional on the selected representation's last modification date being earlier than or equal to the date provided in the field-value. This field accomplishes the same purpose as If-Match for cases where the user agent does not have an entity-tag for the representation.
“If Unmodified Since”标头字段使请求方法以所选表示的上次修改日期早于或等于字段值中提供的日期为条件。对于用户代理没有表示的实体标记的情况，此字段实现与“如果匹配”相同的目的。
If-Unmodified-Since = HTTP-date
If-Unmodified-Since = HTTP-date
An example of the field is:
该字段的一个示例是：
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Unmodified-Since if the request contains an If-Match header field; the condition in If-Match is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-Match.
如果请求包含If-Match标头字段，则收件人必须忽略If未修改；If-Match中的条件被认为是If-Match中的条件的更精确的替代，因为If-Match未被修改，并且这两个条件的结合只是为了与可能不实现If-Match的较旧中介体进行互操作。
A recipient MUST ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.
如果收到的字段值不是有效的HTTP日期，则收件人必须忽略If Unmodified Since标头字段。
A recipient MUST interpret an If-Unmodified-Since field-value's timestamp in terms of the origin server's clock.
收件人必须根据源服务器的时钟解释If未修改的自字段值的时间戳。
If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the selected representation does not match one already stored (or partially stored) from a prior request.
If Unmodified Since最常用于状态更改方法（例如，POST、PUT、DELETE），以防止多个用户代理并行处理不提供实体标记及其表示的资源时发生意外覆盖（即，防止“丢失更新”问题）。如果选定的表示形式与先前请求中已存储（或部分存储）的表示形式不匹配，则它还可以与安全方法一起用于中止请求。
An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition prior to performing the method (Section 5). The origin server MUST NOT perform the requested method if the selected representation's last modification date is more recent than the date provided in the field-value; instead the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent). In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
接收If Unmodified Since标头字段的源服务器必须在执行该方法之前评估该条件（第5节）。如果所选表示的上次修改日期比字段值中提供的日期更晚，则源服务器不得执行请求的方法；相反，如果源服务器已验证正在请求状态更改，且最终状态已反映在目标资源的当前状态中，则源服务器必须使用a）412（前提条件失败）状态代码或b）2xx（成功）状态代码之一进行响应（即，用户代理请求的更改已经成功，但用户代理可能没有意识到这一点，因为先前的响应消息已丢失，或者某个其他用户代理进行了兼容的更改）。在后一种情况下，源服务器不得在响应中发送validator标头字段，除非它可以验证该请求是否与同一用户代理之前所做的更改重复。
The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
If Unmodified Since header字段可被缓存和中介忽略，因为它不适用于存储的响应。
The "If-Range" header field provides a special conditional request mechanism that is similar to the If-Match and If-Unmodified-Since header fields but that instructs the recipient to ignore the Range header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 (Precondition Failed) response. If-Range is defined in Section 3.2 of [RFC7233].
“If Range”标头字段提供了一种特殊的条件请求机制，该机制类似于If匹配，并且如果自标头字段未修改，则指示收件人在验证程序不匹配时忽略范围标头字段，从而导致传输新选择的表示，而不是412（前提条件失败）回答如果范围在[RFC7233]第3.2节中定义。
The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request
304（未修改）状态代码表示已接收到条件GET或HEAD请求，如果不是因为条件评估为false，则可能会导致200（OK）响应。换句话说，服务器不需要传输目标资源的表示，因为请求指示发出请求的客户端
conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a 200 (OK) response.
有条件的，已经有有效的陈述；因此，服务器重定向客户端以使用该存储的表示，就好像它是200（OK）响应的有效负载一样。
The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
生成304响应的服务器必须生成以下任何标头字段，这些字段将在200（确定）响应中发送到同一请求：缓存控制、内容位置、日期、ETag、过期和更改。
Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).
由于304响应的目标是在接收者已经有一个或多个缓存表示时最小化信息传输，因此发送者不应生成除上述字段以外的表示元数据，除非存在所述元数据用于指导缓存更新（例如，如果响应没有ETag字段，则最后修改可能有用）。
Requirements on a cache that receives a 304 response are defined in Section 4.3.4 of [RFC7234]. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client.
[RFC7234]第4.3.4节定义了对接收304响应的缓存的要求。如果条件请求源自出站客户端，例如具有自己缓存的用户代理向共享代理发送条件GET，则代理应将304响应转发给该客户端。
A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.
304响应不能包含消息体；它总是由标题字段后的第一个空行终止。
The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.
412（前置条件失败）状态代码表示在服务器上测试时，请求标头字段中给定的一个或多个条件评估为false。此响应代码允许客户机对当前资源状态（其当前表示和元数据）设置前提条件，从而在目标资源处于意外状态时阻止应用请求方法。
Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would perform the action associated with the request method. A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
除非下面排除，否则收件人缓存或源服务器必须在成功执行其正常请求检查后，以及在执行与请求方法相关联的操作之前，评估接收到的请求的先决条件。如果服务器对没有这些条件的同一请求的响应不是2xx（成功）或412（先决条件失败），则服务器必须忽略所有接收到的先决条件。换句话说，在条件请求中，重定向和失败优先于先决条件的计算。
A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT evaluate the conditional request header fields defined by this specification, and it MUST forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can provide a current representation. Likewise, a server MUST ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a selected representation, such as CONNECT, OPTIONS, or TRACE.
不是目标资源的源服务器且不能作为目标资源上请求的缓存的服务器不得计算此规范定义的条件请求标头字段，并且如果请求被转发，则必须转发这些字段，因为生成客户端希望由能够提供当前表示的服务器对它们进行评估。同样，当使用不涉及选择或修改所选表示（如CONNECT、OPTIONS或TRACE）的请求方法接收时，服务器必须忽略本规范定义的条件请求头字段。
Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field ([RFC4918], Section 10.4).
HTTP扩展定义的条件请求头字段可能会对所有收件人、目标资源的状态或一组资源设置条件。例如，WebDAV中的“If”头字段可以根据多个资源的各个方面（如锁）发出请求，前提是收件人理解并实现该字段（[RFC4918]，第10.4节）。
Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a 304 (Not Modified) response and more useful than a 412 (Precondition Failed) response.
尽管条件请求标头字段被定义为可用于HEAD方法（以保持HEAD的语义与GET的语义一致），但发送条件HEAD没有任何意义，因为成功的响应与304（未修改）响应的大小大致相同，并且比412（先决条件失败）响应更有用。
When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than a partial response, and entity tags are presumed to be more accurate than date validators.
当一个请求中存在多个条件请求标头字段时，字段的求值顺序变得很重要。在实践中，本文档中定义的字段始终以单一的逻辑顺序实现，因为“丢失更新”前提条件的要求比缓存验证更严格，经过验证的缓存比部分响应更有效，并且实体标记被认为比日期验证器更准确。
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:
收件人缓存或源服务器必须按以下顺序评估本规范定义的请求先决条件：
1. When recipient is the origin server and If-Match is present, evaluate the If-Match precondition:
1. 当收件人是源服务器且存在匹配时，请评估是否匹配前提条件：
* if true, continue to step 3
* 如果为true，则继续执行步骤3
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.1)
* 如果为false，则响应412（前提条件失败），除非可以确定状态更改请求已经成功（参见第3.1节）
2. When recipient is the origin server, If-Match is not present, and If-Unmodified-Since is present, evaluate the If-Unmodified-Since precondition:
2. 当收件人是源服务器时，如果不存在匹配项，并且如果存在未修改的自，请计算If Unmodified Since前提条件：
* if true, continue to step 3
* 如果为true，则继续执行步骤3
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.4)
* 如果为false，则响应412（前提条件失败），除非可以确定状态更改请求已经成功（参见第3.4节）
3. When If-None-Match is present, evaluate the If-None-Match precondition:
3. 如果不存在“如果不匹配”，请评估“如果不匹配”前提条件：
* if true, continue to step 5
* 如果为true，则继续执行步骤5
* if false for GET/HEAD, respond 304 (Not Modified)
* 如果GET/HEAD为false，则响应304（未修改）
* if false for other methods, respond 412 (Precondition Failed)
* 如果其他方法为false，则响应412（前提条件失败）
4. When the method is GET or HEAD, If-None-Match is not present, and If-Modified-Since is present, evaluate the If-Modified-Since precondition:
4. 当方法为GET或HEAD时，如果不存在匹配项，并且如果存在修改的自，则评估“如果修改的自”前提条件：
* if true, continue to step 5
* 如果为true，则继续执行步骤5
* if false, respond 304 (Not Modified)
* 如果为false，则响应304（未修改）
5. When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition:
5. 当方法为GET且范围和If范围都存在时，评估If范围前提条件：
* if the validator matches and the Range specification is applicable to the selected representation, respond 206 (Partial Content) [RFC7233]
* 如果验证器匹配且范围规范适用于所选表示，则响应206（部分内容）[RFC7233]
6. Otherwise,
6. 否则
* all conditions are met, so perform the requested action and respond according to its success or failure.
* 所有条件都满足，因此执行请求的操作并根据其成功或失败进行响应。
Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.
定义附加条件请求头字段的HTTP/1.1的任何扩展都应该定义它自己对与本文档中定义的字段和实践中可能发现的其他条件相关的字段求值顺序的期望。
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <http://www.iana.org/assignments/http-status-codes> has been updated with the registrations below:
“超文本传输协议（HTTP）状态代码注册表”位于<http://www.iana.org/assignments/http-status-codes>已更新以下注册信息：
+-------+---------------------+-------------+
| Value | Description | Reference |
+-------+---------------------+-------------+
| 304 | Not Modified | Section 4.1 |
| 412 | Precondition Failed | Section 4.2 |
+-------+---------------------+-------------+
+-------+---------------------+-------------+
| Value | Description | Reference |
+-------+---------------------+-------------+
| 304 | Not Modified | Section 4.1 |
| 412 | Precondition Failed | Section 4.2 |
+-------+---------------------+-------------+
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see [BCP90]):
本文档定义了以下HTTP头字段，因此已根据下面的永久注册更新了其关联的注册表项（请参见[BCP90]）：
+---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+
| ETag | http | standard | Section 2.3 |
| If-Match | http | standard | Section 3.1 |
| If-Modified-Since | http | standard | Section 3.3 |
| If-None-Match | http | standard | Section 3.2 |
| If-Unmodified-Since | http | standard | Section 3.4 |
| Last-Modified | http | standard | Section 2.2 |
+---------------------+----------+----------+-------------+
+---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+
| ETag | http | standard | Section 2.3 |
| If-Match | http | standard | Section 3.1 |
| If-Modified-Since | http | standard | Section 3.3 |
| If-None-Match | http | standard | Section 3.2 |
| If-Unmodified-Since | http | standard | Section 3.4 |
| Last-Modified | http | standard | Section 2.2 |
+---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP conditional request mechanisms. More general security considerations are addressed in HTTP "Message Syntax and Routing" [RFC7230] and "Semantics and Content" [RFC7231].
本节旨在告知开发人员、信息提供者和用户HTTP条件请求机制特有的已知安全问题。HTTP“消息语法和路由”[RFC7230]和“语义和内容”[RFC7231]中阐述了更一般的安全注意事项。
The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.
本规范定义的验证器不用于确保表示的有效性、防止恶意更改或检测中间人攻击。充其量，当所有参与者都表现良好时，它们可以实现更高效的缓存更新和乐观的并发写入。在最坏的情况下，条件将失败，客户端将收到一个比没有条件请求的HTTP交换更有害的响应。
An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.
实体标记可能被滥用，从而产生隐私风险。例如，站点可能故意构造一个语义无效的实体标记，该标记对于用户或用户代理来说是唯一的，以可缓存响应的方式发送该标记并保持较长的刷新时间，然后在以后的条件请求中读取该实体标记，作为重新标识该用户或用户代理的一种方法。只要用户代理保留原始缓存条目，这样的标识标记就会成为持久标识符。缓存表示的用户代理应确保在用户执行隐私维护操作（如清除存储的cookie或更改为私人浏览模式）时清除或替换缓存。
See Section 10 of [RFC7230].
见[RFC7230]第10节。
[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月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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月。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，2014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，2014年6月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，Ed.“Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
The definition of validator weakness has been expanded and clarified. (Section 2.1)
验证程序弱点的定义已经扩展和澄清。（第2.1节）
Weak entity-tags are now allowed in all requests except range requests. (Sections 2.1 and 3.2)
弱实体标记现在允许在除范围请求之外的所有请求中使用。（第2.1节和第3.2节）
The ETag header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (Section 2.3)
ETag头字段ABNF已更改为不使用带引号的字符串，从而避免了转义问题。（第2.3节）
ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various situations (such as a PUT response). (Section 2.3)
ETag被定义为为所选表示提供实体标记，从而阐明它在各种情况下（例如PUT响应）的应用。（第2.3节）
The precedence for evaluation of conditional requests has been defined. (Section 6)
已定义条件请求求值的优先级。（第6节）
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), 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（CR LF）、CTL（控件）、Digital（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、LF（换行符）、OCTET（任何8位数据序列）、SP（空格）和VCHAR（任何可见的US-ASCII字符）。
The rules below are defined in [RFC7230]:
[RFC7230]中定义了以下规则：
OWS = <OWS, see [RFC7230], Section 3.2.3>
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
OWS = <OWS, see [RFC7230], Section 3.2.3>
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
The rules below are defined in other parts:
以下规则在其他部分中定义：
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
在下面收集的ABNF中，列表规则按照[RFC7230]的第1.2节展开。
ETag = entity-tag
ETag = entity-tag
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Unmodified-Since = HTTP-date
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date
Last-Modified = HTTP-date
OWS = <OWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text
entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/
weak = %x57.2F ; W/
Index
指数
3 304 Not Modified (status code) 19
3 304未修改（状态代码）19
4 412 Precondition Failed (status code) 18
4 412前提条件失败（状态代码）18
E ETag header field 9
E ETag头字段9
G Grammar entity-tag 9 ETag 9 etagc 9 If-Match 13 If-Modified-Since 15 If-None-Match 14 If-Unmodified-Since 17 Last-Modified 7 opaque-tag 9 weak 9
语法实体标记9 ETag 9 etagc 9 If Match 13 If Modified Since 15 If None Match 14 If Unmodified Since 17 Last Modified 7不透明标记9弱9
I If-Match header field 13 If-Modified-Since header field 16 If-None-Match header field 14 If-Unmodified-Since header field 17
I如果匹配标头字段13（如果自标头字段17修改），如果没有匹配标头字段14（如果自标头字段17未修改）
L Last-Modified header field 7
L上次修改的标题字段7
M metadata 5
M元数据5
S selected representation 4
S选定的代表4
V validator 5 strong 5 weak 5
V验证器5强5弱5
Authors' Addresses
作者地址
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Roy T.Fielding（编辑）美国加利福尼亚州圣何塞公园大道345号Adobe系统公司，邮编95110
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/