Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7234 Adobe
Obsoletes: 2616 M. Nottingham, Ed.
Category: Standards Track Akamai
ISSN: 2070-1721 J. Reschke, Ed.
greenbytes
June 2014
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7234 Adobe
Obsoletes: 2616 M. Nottingham, Ed.
Category: Standards Track Akamai
ISSN: 2070-1721 J. Reschke, Ed.
greenbytes
June 2014
Hypertext Transfer Protocol (HTTP/1.1): Caching
超文本传输协议（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 caches and the associated header fields that control cache behavior or indicate cacheable response messages.
超文本传输协议（HTTP）是用于分布式、协作式超文本信息系统的无状态应用程序级协议。本文档定义了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/rfc7234.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7234.
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
1.2.1. Delta Seconds .......................................5
2. Overview of Cache Operation .....................................5
3. Storing Responses in Caches .....................................6
3.1. Storing Incomplete Responses ...............................7
3.2. Storing Responses to Authenticated Requests ................7
3.3. Combining Partial Content ..................................8
4. Constructing Responses from Caches ..............................8
4.1. Calculating Secondary Keys with Vary .......................9
4.2. Freshness .................................................11
4.2.1. Calculating Freshness Lifetime .....................12
4.2.2. Calculating Heuristic Freshness ....................13
4.2.3. Calculating Age ....................................13
4.2.4. Serving Stale Responses ............................15
4.3. Validation ................................................16
4.3.1. Sending a Validation Request .......................16
4.3.2. Handling a Received Validation Request .............16
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
1.2.1. Delta Seconds .......................................5
2. Overview of Cache Operation .....................................5
3. Storing Responses in Caches .....................................6
3.1. Storing Incomplete Responses ...............................7
3.2. Storing Responses to Authenticated Requests ................7
3.3. Combining Partial Content ..................................8
4. Constructing Responses from Caches ..............................8
4.1. Calculating Secondary Keys with Vary .......................9
4.2. Freshness .................................................11
4.2.1. Calculating Freshness Lifetime .....................12
4.2.2. Calculating Heuristic Freshness ....................13
4.2.3. Calculating Age ....................................13
4.2.4. Serving Stale Responses ............................15
4.3. Validation ................................................16
4.3.1. Sending a Validation Request .......................16
4.3.2. Handling a Received Validation Request .............16
4.3.3. Handling a Validation Response .....................18
4.3.4. Freshening Stored Responses upon Validation ........18
4.3.5. Freshening Responses via HEAD ......................19
4.4. Invalidation ..............................................20
5. Header Field Definitions .......................................21
5.1. Age .......................................................21
5.2. Cache-Control .............................................21
5.2.1. Request Cache-Control Directives ...................22
5.2.2. Response Cache-Control Directives ..................24
5.2.3. Cache Control Extensions ...........................27
5.3. Expires ...................................................28
5.4. Pragma ....................................................29
5.5. Warning ...................................................29
5.5.1. Warning: 110 - "Response is Stale" .................31
5.5.2. Warning: 111 - "Revalidation Failed" ...............31
5.5.3. Warning: 112 - "Disconnected Operation" ............31
5.5.4. Warning: 113 - "Heuristic Expiration" ..............31
5.5.5. Warning: 199 - "Miscellaneous Warning" .............32
5.5.6. Warning: 214 - "Transformation Applied" ............32
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
6. History Lists ..................................................32
7. IANA Considerations ............................................32
7.1. Cache Directive Registry ..................................32
7.1.1. Procedure ..........................................32
7.1.2. Considerations for New Cache Control Directives ....33
7.1.3. Registrations ......................................33
7.2. Warn Code Registry ........................................34
7.2.1. Procedure ..........................................34
7.2.2. Registrations ......................................34
7.3. Header Field Registration .................................34
8. Security Considerations ........................................35
9. Acknowledgments ................................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A. Changes from RFC 2616 .................................38
Appendix B. Imported ABNF .........................................39
Appendix C. Collected ABNF ........................................39
Index .............................................................41
4.3.3. Handling a Validation Response .....................18
4.3.4. Freshening Stored Responses upon Validation ........18
4.3.5. Freshening Responses via HEAD ......................19
4.4. Invalidation ..............................................20
5. Header Field Definitions .......................................21
5.1. Age .......................................................21
5.2. Cache-Control .............................................21
5.2.1. Request Cache-Control Directives ...................22
5.2.2. Response Cache-Control Directives ..................24
5.2.3. Cache Control Extensions ...........................27
5.3. Expires ...................................................28
5.4. Pragma ....................................................29
5.5. Warning ...................................................29
5.5.1. Warning: 110 - "Response is Stale" .................31
5.5.2. Warning: 111 - "Revalidation Failed" ...............31
5.5.3. Warning: 112 - "Disconnected Operation" ............31
5.5.4. Warning: 113 - "Heuristic Expiration" ..............31
5.5.5. Warning: 199 - "Miscellaneous Warning" .............32
5.5.6. Warning: 214 - "Transformation Applied" ............32
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
6. History Lists ..................................................32
7. IANA Considerations ............................................32
7.1. Cache Directive Registry ..................................32
7.1.1. Procedure ..........................................32
7.1.2. Considerations for New Cache Control Directives ....33
7.1.3. Registrations ......................................33
7.2. Warn Code Registry ........................................34
7.2.1. Procedure ..........................................34
7.2.2. Registrations ......................................34
7.3. Header Field Registration .................................34
8. Security Considerations ........................................35
9. Acknowledgments ................................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A. Changes from RFC 2616 .................................38
Appendix B. Imported ABNF .........................................39
Appendix C. Collected ABNF ........................................39
Index .............................................................41
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.
HTTP通常用于分布式信息系统，通过使用响应缓存可以提高性能。本文档定义了HTTP/1.1中与缓存和重用响应消息相关的方面。
An HTTP cache is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
HTTP缓存是响应消息的本地存储以及控制其中消息的存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户机或服务器都可以使用缓存，但作为隧道的服务器不能使用缓存。
A shared cache is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A private cache, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.
共享缓存是一种缓存，用于存储多个用户重用的响应；共享缓存通常（但并非总是）部署为中介的一部分。相反，私有缓存专用于单个用户；通常，它们被部署为用户代理的一个组件。
The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in Section 4.2, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (Section 4.3) or if the origin is unavailable (Section 4.2.4).
HTTP/1.1中缓存的目标是通过重用先前的响应消息来满足当前请求，从而显著提高性能。如第4.2节所定义，如果响应可以在没有“验证”的情况下重复使用，则存储的响应将被视为“新的”（与源服务器进行检查，以查看缓存的响应对此请求是否仍然有效）。因此，每次重用新响应时，它都可以减少延迟和网络开销。当缓存的响应不新鲜时，如果可以通过验证（第4.3节）对其进行刷新，或者如果原始响应不可用（第4.2.4节），则该响应仍可以重用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
[RFC7230]第2.5节定义了与错误处理相关的一致性标准和注意事项。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates
本规范使用[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表示法。
The delta-seconds rule specifies a non-negative integer, representing time in seconds.
delta seconds规则指定一个非负整数，以秒为单位表示时间。
delta-seconds = 1*DIGIT
delta-seconds = 1*DIGIT
A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be either 2147483648 (2^31) or the greatest positive integer it can conveniently represent.
解析delta seconds值并将其转换为二进制形式的收件人应使用至少31位非负整数范围的算术类型。如果缓存接收到一个大于它所能表示的最大整数的δ秒值，或者如果其后续计算中的任何一个溢出，则缓存必须考虑该值为2147483648（2 ^ 31）或它可以方便地表示的最大正整数。
Note: The value 2147483648 is here for historical reasons, effectively represents infinity (over 68 years), and does not need to be stored in binary form; an implementation could produce it as a canned string if any overflow occurs, even if the calculations are performed with an arithmetic type incapable of directly representing that number. What matters here is that an overflow be detected and not treated as a negative value in later calculations.
注：由于历史原因，此处的值2147483648实际上代表无限（超过68年），不需要以二进制形式存储；如果发生任何溢出，即使使用无法直接表示该数字的算术类型执行计算，实现也可以将其生成为屏蔽字符串。这里重要的是检测溢出，而不是在以后的计算中将其视为负值。
Proper cache operation preserves the semantics of HTTP transfers ([RFC7231]) while eliminating the transfer of information already held in the cache. Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.
正确的缓存操作保留HTTP传输（[RFC7231]）的语义，同时消除缓存中已有信息的传输。尽管缓存是HTTP的一个完全可选的特性，但是可以假设重用缓存响应是可取的，并且当没有任何需求或本地配置阻止它时，这种重用是默认行为。因此，HTTP缓存要求的重点是防止缓存存储不可重用的响应或不适当地重用存储的响应，而不是强制要求缓存始终存储和重用特定的响应。
Each cache entry consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response to a GET request, which contains a representation of the resource identified by the request target (Section 4.3.1 of [RFC7231]). However, it is also possible to cache permanent redirects, negative results (e.g., 404 (Not Found)),
每个缓存项由一个缓存密钥和一个或多个HTTP响应组成，这些响应对应于使用相同密钥的先前请求。最常见的缓存项形式是检索请求的成功结果：即对GET请求的200（OK）响应，其中包含请求目标（RFC7231）第4.3.1节）标识的资源表示。但是，也可以缓存永久重定向、负面结果（例如404（未找到）），
incomplete results (e.g., 206 (Partial Content)), and responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.
不完整的结果（例如206（部分内容）），以及对GET以外的方法的响应，前提是该方法的定义允许此类缓存并定义了适合用作缓存键的内容。
The primary cache key consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.
主缓存键由请求方法和目标URI组成。然而，由于目前常用的HTTP缓存通常仅限于缓存要获取的响应，因此许多缓存只是拒绝使用其他方法，而仅使用URI作为主缓存键。
If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (Section 4.1).
如果请求目标要进行内容协商，则其缓存条目可能由多个存储的响应组成，每个响应由原始请求的选择头字段值的辅助键区分（第4.1节）。
A cache MUST NOT store a response to any request, unless:
缓存不得存储对任何请求的响应，除非：
o The request method is understood by the cache and defined as being cacheable, and
o 请求方法被缓存理解并定义为可缓存，以及
o the response status code is understood by the cache, and
o 缓存可以理解响应状态代码，并且
o the "no-store" cache directive (see Section 5.2) does not appear in request or response header fields, and
o “无存储”缓存指令（见第5.2节）未出现在请求或响应标题字段中，以及
o the "private" response directive (see Section 5.2.2.6) does not appear in the response, if the cache is shared, and
o 如果缓存是共享的，则“private”响应指令（见第5.2.2.6节）不会出现在响应中，并且
o the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see Section 3.2), and
o 如果缓存是共享的，则授权标头字段（参见[RFC7235]第4.2节）不会出现在请求中，除非响应明确允许（参见第3.2节），并且
o the response either:
o 答复如下：
* contains an Expires header field (see Section 5.3), or
* 包含Expires标头字段（参见第5.3节），或
* contains a max-age response directive (see Section 5.2.2.8), or
* 包含最大年龄响应指令（见第5.2.2.8节），或
* contains a s-maxage response directive (see Section 5.2.2.9) and the cache is shared, or
* 包含s-maxage响应指令（见第5.2.2.9节），且缓存是共享的，或
* contains a Cache Control Extension (see Section 5.2.3) that allows it to be cached, or
* 包含允许缓存的缓存控制扩展（参见第5.2.3节），或
* has a status code that is defined as cacheable by default (see Section 4.2.2), or
* 具有默认定义为可缓存的状态代码（参见第4.2.2节），或
* contains a public response directive (see Section 5.2.2.5).
* 包含公共响应指令（见第5.2.2.5节）。
Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.
请注意，上面列出的任何要求都可以被缓存控制扩展覆盖；见第5.2.3节。
In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all specified caching-related behavior.
在此上下文中，如果缓存能够识别请求方法或响应状态代码并实现所有指定的缓存相关行为，那么它已经“理解”了请求方法或响应状态代码。
Note that, in normal operation, some caches will not store a response that has neither a cache validator nor an explicit expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
请注意，在正常操作中，某些缓存不会存储既没有缓存验证器也没有显式过期时间的响应，因为这样的响应通常不会用于存储。但是，缓存并不禁止存储此类响应。
A response message is considered complete when all of the octets indicated by the message framing ([RFC7230]) are received prior to the connection being closed. If the request method is GET, the response status code is 200 (OK), and the entire response header section has been received, a cache MAY store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) response MAY be stored as if it were an incomplete 200 (OK) cache entry. However, a cache MUST NOT store incomplete or partial-content responses if it does not support the Range and Content-Range header fields or if it does not understand the range units used in those fields.
当在连接关闭之前接收到消息帧（[RFC7230]）指示的所有八位字节时，响应消息被视为完成。如果请求方法为GET，响应状态代码为200（OK），并且已接收到整个响应头部分，则如果缓存条目记录为不完整，则缓存可能会存储不完整的响应消息正文。类似地，206（部分内容）响应可以被存储，就好像它是不完整的200（OK）缓存条目一样。但是，如果缓存不支持范围和内容范围标题字段，或者不了解这些字段中使用的范围单位，则缓存不得存储不完整或部分内容响应。
A cache MAY complete a stored incomplete response by making a subsequent range request ([RFC7233]) and combining the successful response with the stored entry, as defined in Section 3.3. A cache MUST NOT use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies a range that is wholly within the incomplete response. A cache MUST NOT send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
缓存可通过发出后续范围请求（[RFC7233]）并将成功响应与存储条目相结合来完成存储的不完整响应，如第3.3节所定义。缓存不得使用不完整响应来响应请求，除非响应已完成或请求是部分的，并且指定了完全在不完整响应内的范围。缓存在未使用206（部分内容）状态代码明确标记的情况下，不得向客户端发送部分响应。
A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 4.2 of [RFC7235]) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
除非响应中存在允许存储此类响应的缓存指令，否则共享缓存不得使用带有授权标头字段的请求缓存响应（RFC7235第4.2节）来满足任何后续请求。
In this specification, the following Cache-Control response directives (Section 5.2.2) have such an effect: must-revalidate, public, and s-maxage.
在本规范中，以下缓存控制响应指令（第5.2.2节）具有这样的效果：必须重新验证、公共和s-maxage。
Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale (Section 4.2.4) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server.
请注意，包含“必须重新验证”和/或“s-maxage”响应指令的缓存响应不允许由共享缓存提供过时（第4.2.4节）。特别是，“max age=0，必须重新验证”或“s-maxage=0”的响应不能用于满足后续请求，而必须在源服务器上重新验证它。
A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers ([RFC7233]). After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in Section 4.3 of [RFC7233].
如果连接过早关闭或请求使用了一个或多个范围说明符（[RFC7233]），则响应可能仅传输部分表示。在多次这样的传输之后，缓存可能已经接收到相同表示的多个范围。缓存可以将这些范围组合成单个存储响应，并重用该响应以满足后续请求，前提是它们都共享同一个强验证器，并且缓存符合[RFC7233]第4.3节中的客户要求。
When combining the new response with one or more stored responses, a cache MUST:
将新响应与一个或多个存储的响应组合时，缓存必须：
o delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
o 删除存储响应中警告代码为1xx的任何警告标题字段（见第5.5节）；
o retain any Warning header fields in the stored response with warn-code 2xx; and,
o 在存储的响应中保留任何警告标题字段，警告代码为2xx；和
o use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.
o 使用新响应中提供的其他头字段（内容范围除外）替换存储响应中相应头字段的所有实例。
When presented with a request, a cache MUST NOT reuse a stored response, unless:
当呈现请求时，缓存不得重用存储的响应，除非：
o The presented effective request URI (Section 5.5 of [RFC7230]) and that of the stored response match, and
o 提供的有效请求URI（RFC7230第5.5节）和存储响应匹配的URI，以及
o the request method associated with the stored response allows it to be used for the presented request, and
o 与存储响应关联的请求方法允许将其用于呈现的请求，以及
o selecting header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
o 选择存储响应（如果有）指定的标题字段与显示的标题字段匹配（见第4.1节），以及
o the presented request does not contain the no-cache pragma (Section 5.4), nor the no-cache cache directive (Section 5.2.1), unless the stored response is successfully validated (Section 4.3), and
o 提交的请求不包含no cache pragma（第5.4节），也不包含no cache cache指令（第5.2.1节），除非存储的响应已成功验证（第4.3节），并且
o the stored response does not contain the no-cache cache directive (Section 5.2.2.2), unless it is successfully validated (Section 4.3), and
o 存储的响应不包含no cache cache指令（第5.2.2.2节），除非成功验证（第4.3节），以及
o the stored response is either:
o 存储的响应为：
* fresh (see Section 4.2), or
* 新鲜（见第4.2节），或
* allowed to be served stale (see Section 4.2.4), or
* 允许陈腐食用（见第4.2.4节），或
* successfully validated (see Section 4.3).
* 成功验证（见第4.3节）。
Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.
请注意，上面列出的任何要求都可以被缓存控制扩展覆盖；见第5.2.3节。
When a stored response is used to satisfy a request without validation, a cache MUST generate an Age header field (Section 5.1), replacing any present in the response with a value equal to the stored response's current_age; see Section 4.2.3.
当使用存储响应来满足请求而不进行验证时，缓存必须生成一个年龄头字段（第5.1节），用一个等于存储响应当前年龄的值替换响应中的任何内容；见第4.2.3节。
A cache MUST write through requests with methods that are unsafe (Section 4.2.1 of [RFC7231]) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.
缓存必须使用不安全的方法（RFC7231的第4.2.1节）将请求写入源服务器；i、 例如，在转发请求并接收到相应响应之前，不允许缓存生成对该请求的回复。
Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4.
另外，请注意，不安全的请求可能会使已存储的响应无效；见第4.4节。
When more than one suitable response is stored, a cache MUST use the most recent response (as determined by the Date header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
当存储了多个合适的响应时，缓存必须使用最新的响应（由Date header字段确定）。它还可以使用“缓存控制：最大年龄=0”或“缓存控制：无缓存”转发请求，以消除使用哪个响应的歧义。
A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use.
没有可用时钟的缓存在每次使用时都必须重新验证存储的响应，才能使用存储的响应。
When a cache receives a request that can be satisfied by a stored response that has a Vary header field (Section 7.1.4 of [RFC7231]), it MUST NOT use that response unless all of the selecting header
当缓存接收到一个请求时，该请求可以由一个存储的响应来满足，该响应具有一个Vary头字段（RFC7231的第7.1.4节），除非所有的选择头
fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request.
Vary头字段指定的字段与原始请求（即与存储的响应相关联的请求）和呈现的请求都匹配。
The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following:
两个请求中的selecting header字段定义为当且仅当第一个请求中的字段可以通过应用以下任一项转换为第二个请求中的字段时匹配：
o adding or removing whitespace, where allowed in the header field's syntax
o 在标题字段语法允许的情况下添加或删除空格
o combining multiple header fields with the same field name (see Section 3.2 of [RFC7230])
o 组合具有相同字段名的多个标题字段（参见[RFC7230]第3.2节）
o normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
o 根据报头字段的规范，以已知具有相同语义的方式规范化两个报头字段值（例如，在顺序不重要时重新排序字段值；大小写规范化，其中值定义为不区分大小写）
If (after any normalization that might take place) a header field is absent from a request, it can only match another request if it is also absent there.
如果（在可能发生的任何规范化之后）一个请求中缺少一个头字段，那么它只能匹配另一个请求（如果该请求也不存在）。
A Vary header field-value of "*" always fails to match.
Vary标头字段值“*”始终无法匹配。
The stored response with matching selecting header fields is known as the selected response.
存储的具有匹配的选择标头字段的响应称为所选响应。
If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on Accept and similar request header fields), that mechanism MAY be used to select preferred responses; of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4.
如果有多个选定的响应可用（可能包括没有“更改头”字段的响应），缓存将需要选择一个来使用。当选择报头字段具有这样做的已知机制（例如，接受和类似请求报头字段上的QValue）时，该机制可用于选择首选响应；根据第4节，在其余响应中，使用最新的响应（由日期标题字段确定）。
If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see Section 4.3) request.
如果没有选择的响应可用，缓存将无法满足所提供的请求。通常，它以（可能是有条件的；请参阅第4.3节）请求的形式转发到源服务器。
A fresh response is one whose age has not yet exceeded its freshness lifetime. Conversely, a stale response is one where it has.
一个新鲜的反应是一个年龄尚未超过其新鲜寿命的反应。相反，一个陈旧的响应是一个已经过时的响应。
A response's freshness lifetime is the length of time between its generation by the origin server and its expiration time. An explicit expiration time is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, whereas a heuristic expiration time is assigned by a cache when no explicit expiration time is available.
响应的freshness lifetime是源服务器生成响应与响应过期之间的时间长度。显式过期时间是源服务器希望缓存在没有进一步验证的情况下不再使用存储的响应的时间，而当没有显式过期时间可用时，缓存将分配启发式过期时间。
A response's age is the time that has passed since it was generated by, or successfully validated with, the origin server.
响应的期限是自原始服务器生成响应或使用原始服务器成功验证响应以来经过的时间。
When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
当响应在缓存中是“新的”时，可以使用它来满足后续请求，而无需联系源服务器，从而提高效率。
The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.8). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.
确定新鲜度的主要机制是源服务器使用Expires标头字段（第5.3节）或max age response指令（第5.2.2.8节）在将来提供明确的过期时间。通常，源服务器将为响应分配未来的显式过期时间，因为它认为在过期时间到达之前，表示不太可能以语义上重要的方式更改。
If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing it for subsequent requests (see Section 4.2.4).
如果源服务器希望强制缓存验证每个请求，它可以指定过去的显式过期时间，以指示响应已经过时。兼容缓存通常会在将过时的缓存响应重新用于后续请求之前对其进行验证（请参阅第4.2.4节）。
Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine an expiration time under certain circumstances (see Section 4.2.2).
由于源服务器并不总是提供明确的过期时间，因此也允许缓存在某些情况下使用启发式方法来确定过期时间（参见第4.2.2节）。
The calculation to determine if a response is fresh is:
确定响应是否为新响应的计算为：
response_is_fresh = (freshness_lifetime > current_age)
response_is_fresh = (freshness_lifetime > current_age)
freshness_lifetime is defined in Section 4.2.1; current_age is defined in Section 4.2.3.
第4.2.1节规定了新鲜度和使用寿命；第4.2.3节对当前年龄进行了定义。
Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the corresponding response (Section 5.2.1).
客户端可以在请求中发送max-age或min-fresh-cache指令，以约束或放松相应响应的新鲜度计算（第5.2.1节）。
When calculating freshness, to avoid common problems in date parsing:
计算新鲜度时，为避免日期解析中的常见问题：
o Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match day, week, and time-zone names case-insensitively.
o 尽管所有日期格式都指定为区分大小写，但缓存收件人应不区分大小写地匹配日期、星期和时区名称。
o If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient MUST internally represent a parsed Expires date as the nearest time equal to or earlier than the received value.
o 如果缓存收件人的内部时间实现的分辨率小于HTTP日期的值，则收件人必须在内部将解析的过期日期表示为等于或早于接收值的最近时间。
o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o 缓存收件人不得允许本地时区影响年龄或到期时间的计算或比较。
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.
o 缓存收件人应考虑除GMT或UTC以外的区域缩写的日期对于计算期满无效。
Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource. See Section 6 for an explanation of the difference between caches and history mechanisms.
请注意，新鲜度仅适用于缓存操作；它不能用于强制用户代理刷新其显示或重新加载资源。有关缓存和历史机制之间差异的解释，请参见第6节。
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of the following:
缓存可以使用以下第一个匹配项计算响应的新鲜度生存期（表示为新鲜度_生存期）：
o If the cache is shared and the s-maxage response directive (Section 5.2.2.9) is present, use its value, or
o 如果缓存是共享的，并且存在s-maxage响应指令（第5.2.2.9节），则使用其值，或
o If the max-age response directive (Section 5.2.2.8) is present, use its value, or
o 如果存在最大寿命响应指令（第5.2.2.8节），则使用其值，或
o If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field, or
o 如果存在Expires响应标题字段（第5.3节），则使用其值减去Date响应标题字段的值，或
o Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see Section 4.2.2.
o 否则，响应中不存在明确的过期时间。启发式新鲜度生命周期可能适用；见第4.2.2节。
Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.
请注意，此计算不易受到时钟偏移的影响，因为所有信息都来自源服务器。
When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged to consider responses that have invalid freshness information to be stale.
当给定指令存在多个值时（例如，两个Expires标头字段、多个缓存控制：max age指令），该指令的值被视为无效。高速缓存被鼓励考虑具有无效新鲜度信息的响应是陈旧的。
Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case constraints on their results.
由于源服务器并不总是提供显式过期时间，因此当未指定显式时间时，缓存可以分配启发式过期时间，使用使用使用其他标头字段值（例如上次修改的时间）的算法来估计合理的过期时间。本规范未提供具体算法，但对其结果施加了最坏情况约束。
A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements in Section 3, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are defined as cacheable by default (see Section 6.1 of [RFC7231]), and those responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive).
当存储的响应中存在显式过期时间时，缓存不得使用启发式来确定新鲜度。由于第3节中的要求，这意味着，有效地，启发式只能用于无显式新鲜度的响应，其状态代码默认定义为可缓存（见[RFC7231]第6.1节），以及那些无显式新鲜度且已标记为可显式缓存的响应（例如，带有“public”）响应指令）。
If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
如果响应具有上次修改的标头字段（RFC7232的第2.2节），则鼓励缓存使用启发式过期值，该值不超过自该时间起间隔的某个分数。该分数的典型设置可能为10%。
When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a Warning header field with a 113 warn-code (see Section 5.5.4) in the response if its current_age is more than 24 hours and such a warning is not already present.
当使用启发式方法计算新鲜度生存期时，如果缓存的当前使用时间超过24小时，且该警告尚未出现，则缓存应在响应中生成带有113警告代码的警告标头字段（见第5.5.4节）。
Note: Section 13.9 of [RFC2616] prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control: no-cache) if they wish to preclude caching.
注：[RFC2616]第13.9节禁止缓存计算带有查询组件的URI的启发式新鲜度（即包含“？”的URI）。在实践中，这并没有得到广泛实施。因此，如果源服务器希望排除缓存，则鼓励它们发送显式指令（例如，缓存控制：无缓存）。
The Age header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is the cache's estimate of the number of seconds since the response was generated or validated by the origin server. In essence, the Age
当从缓存中获取响应消息时，年龄头字段用于传递响应消息的估计年龄。“年龄”字段值是缓存对自原始服务器生成或验证响应以来的秒数的估计。从本质上讲，这个时代
value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths.
值是响应沿源服务器路径驻留在每个缓存中的时间加上响应沿网络路径传输的时间之和。
The following data is used for the age calculation:
以下数据用于年龄计算：
age_value
年龄值
The term "age_value" denotes the value of the Age header field (Section 5.1), in a form appropriate for arithmetic operation; or 0, if not available.
术语“age_值”表示年龄标题字段的值（第5.1节），其形式适合算术运算；或0（如果不可用）。
date_value
日期值
The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See Section 7.1.1.2 of [RFC7231] for the definition of the Date header field, and for requirements regarding responses without it.
术语“date_value”表示日期标题字段的值，其形式适合于算术运算。参见[RFC7231]第7.1.1.2节，了解日期标题字段的定义，以及关于没有该字段的响应的要求。
now
现在
The term "now" means "the current value of the clock at the host performing the calculation". A host ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clocks to Coordinated Universal Time.
术语“现在”是指“执行计算的主机上时钟的当前值”。主机应该使用NTP（[RFC5905]）或类似的协议将其时钟与协调的世界时同步。
request_time
请求时间
The current value of the clock at the host at the time the request resulting in the stored response was made.
产生存储响应的请求发出时主机上时钟的当前值。
response_time
响应时间
The current value of the clock at the host at the time the response was received.
接收到响应时主机上时钟的当前值。
A response's age can be calculated in two entirely independent ways:
响应的年龄可以通过两种完全独立的方式计算：
1. the "apparent_age": response_time minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, the result is replaced by zero.
1. “表观时间”：如果本地时钟与源服务器的时钟同步良好，则响应时间减去日期值。如果结果为负，则结果将替换为零。
2. the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1. A cache MUST interpret this value relative to the time the request was initiated, not the time that the response was received.
2. 如果响应路径上的所有缓存都实现HTTP/1.1，则为“更正的\u age\u值”。缓存必须相对于启动请求的时间而不是接收响应的时间来解释此值。
apparent_age = max(0, response_time - date_value);
apparent_age = max(0, response_time - date_value);
response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;
response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;
These are combined as
这些组合为
corrected_initial_age = max(apparent_age, corrected_age_value);
corrected_initial_age = max(apparent_age, corrected_age_value);
unless the cache is confident in the value of the Age header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value MAY be used as the corrected_initial_age.
除非缓存对年龄标头字段的值有信心（例如，因为在Via标头字段中没有HTTP/1.0跳），否则在这种情况下，可将校正的_Age_值用作校正的_初始_年龄。
The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response was last validated by the origin server to the corrected_initial_age.
然后，可以通过将自存储响应上次由源服务器验证以来的时间量（以秒为单位）与更正的\u初始\u时间相加来计算存储响应的当前\u时间。
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but is not fresh according to the calculations in Section 4.2.
“过时”响应是指具有明确的到期信息或允许计算启发式到期，但根据第4.2节中的计算不新鲜的响应。
A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
如果协议中明确的指令（例如，“无存储”或“无缓存”缓存指令、“必须重新验证”缓存响应指令，或适用的“s-maxage”或“代理重新验证”缓存响应指令；参见第5.2.2节）禁止缓存生成过期响应，则缓存不得生成过期响应。
A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max-stale request directive; see Section 5.2.1).
缓存不得发送过时响应，除非它断开连接（即，它无法联系原始服务器或以其他方式找到转发路径），或者明确允许这样做（例如，通过max stale request指令；请参阅第5.2.1节）。
A cache SHOULD generate a Warning header field with the 110 warn-code (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD generate a 112 warn-code (see Section 5.5.3) in stale responses if the cache is disconnected.
缓存应在过时响应中生成一个带有110警告代码（见第5.5.1节）的警告标头字段。同样，如果缓存断开连接，缓存应在过时响应中生成112警告代码（参见第5.5.3节）。
A cache SHOULD NOT generate a new Warning header field when forwarding a response that does not have an Age header field, even if the response is already stale. A cache need not validate a response that merely became stale in transit.
在转发没有年龄标头字段的响应时，缓存不应生成新的警告标头字段，即使该响应已过时。缓存不需要验证仅在传输过程中过时的响应。
When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or one cannot be selected; see Section 4.1), it can use the conditional request mechanism [RFC7232] in the forwarded request to give the next inbound server an opportunity to select a valid stored response to use, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as "validating" or "revalidating" the stored response.
当缓存对请求的URI有一个或多个存储响应，但无法为其中任何一个提供服务时（例如，因为它们不是最新的，或者无法选择一个响应；请参见第4.1节），它可以在转发的请求中使用条件请求机制[RFC7232]，为下一个入站服务器提供选择要使用的有效存储响应的机会，更新进程中存储的元数据，或用新响应替换存储的响应。此过程称为“验证”或“重新验证”存储的响应。
When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing validator metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource.
当发送缓存验证的条件请求时，缓存从其存储的响应中发送一个或多个包含验证器元数据的前提条件标头字段，然后由收件人进行比较，以确定存储的响应是否等效于资源的当前表示形式。
One such validator is the timestamp given in a Last-Modified header field (Section 2.2 of [RFC7232]), which can be used in an If-Modified-Since header field for response validation, or in an If-Unmodified-Since or If-Range header field for representation selection (i.e., the client is referring specifically to a previously obtained representation with that timestamp).
其中一个验证器是上次修改的标头字段（RFC7232的第2.2节）中给出的时间戳，该时间戳可用于If-Modified-Since标头字段以进行响应验证，或用于If-Unmodified-Since或If-Range标头字段以进行表示选择（即，客户具体指的是之前获得的带有该时间戳的表示）。
Another validator is the entity-tag given in an ETag header field (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one or more stored responses, can be used in an If-None-Match header field for response validation, or in an If-Match or If-Range header field for representation selection (i.e., the client is referring specifically to one or more previously obtained representations with the listed entity-tags).
另一个验证器是ETag头字段中给出的实体标记（RFC7232的第2.3节）。指示一个或多个存储响应的一个或多个实体标记可用于响应验证的If None Match标头字段中，或用于表示选择的If Match或If Range标头字段中（即，客户使用列出的实体标记专门指代一个或多个先前获得的表示）。
Each client in the request chain may have its own cache, so it is common for a cache at an intermediary to receive conditional requests from other (outbound) caches. Likewise, some user agents make use of conditional requests to limit data transfers to recently modified representations or to complete the transfer of a partially retrieved representation.
请求链中的每个客户机都可能有自己的缓存，因此中间层的缓存通常会从其他（出站）缓存接收有条件的请求。同样，一些用户代理使用条件请求将数据传输限制为最近修改的表示，或完成部分检索到的表示的传输。
If a cache receives a request that can be satisfied by reusing one of its stored 200 (OK) or 206 (Partial Content) responses, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators contained within the selected response. A cache MUST NOT evaluate
如果缓存接收到可以通过重用其存储的200（确定）或206（部分内容）响应之一来满足的请求，则缓存应针对所选响应中包含的相应验证器，评估该请求中接收到的任何适用的条件头字段先决条件。缓存不能进行计算
conditional header fields that are only applicable to an origin server, found in a request with semantics that cannot be satisfied with a cached response, or applied to a target resource for which it has no stored responses; such preconditions are likely intended for some other (inbound) server.
仅适用于源服务器的条件头字段，可在语义不能满足缓存响应的请求中找到，或应用于没有存储响应的目标资源；这些先决条件可能适用于其他（入站）服务器。
The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence, as defined in Section 6 of [RFC7232]. The If-Match and If-Unmodified-Since conditional header fields are not applicable to a cache.
根据[RFC7232]第6节中的定义，缓存对条件请求的正确评估取决于收到的前提条件标头字段及其优先级。If匹配和If未修改，因为条件标头字段不适用于缓存。
A request containing an If-None-Match header field (Section 3.2 of [RFC7232]) indicates that the client wants to validate one or more of its own stored responses in comparison to whichever stored response is selected by the cache. If the field-value is "*", or if the field-value is a list of entity-tags and at least one of them matches the entity-tag of the selected stored response, a cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) instead of sending that stored response.
包含If None Match头字段的请求（RFC7232的第3.2节）表示客户机希望验证一个或多个自己存储的响应，与缓存选择的存储响应进行比较。如果字段值为“*”，或者如果字段值是实体标记列表，并且其中至少有一个与所选存储响应的实体标记匹配，则缓存收件人应生成304（未修改）响应（使用所选存储响应的元数据），而不是发送该存储响应。
When a cache decides to revalidate its own stored responses for a request that contains an If-None-Match list of entity-tags, the cache MAY combine the received list with a list of entity-tags from its own stored set of responses (fresh or stale) and send the union of the two lists as a replacement If-None-Match header field value in the forwarded request. If a stored response contains only partial content, the cache MUST NOT include its entity-tag in the union unless the request is for a range that would be fully satisfied by that partial stored response. If the response to the forwarded request is 304 (Not Modified) and has an ETag header field value with an entity-tag that is not in the client's list, the cache MUST generate a 200 (OK) response for the client by reusing its corresponding stored response, as updated by the 304 response metadata (Section 4.3.4).
当缓存决定对包含“如果不匹配”实体标记列表的请求重新验证其自己存储的响应时，缓存可以将接收到的列表与来自其自己存储的响应集（新鲜或陈旧）的实体标记列表相结合如果转发的请求中没有匹配头字段值的列表，则发送两个列表的并集作为替换。如果存储的响应仅包含部分内容，则缓存不得在联合中包含其实体标记，除非请求的范围将由该部分存储的响应完全满足。如果对转发请求的响应为304（未修改），并且具有ETag头字段值，且实体标记不在客户端列表中，则缓存必须通过重用其相应的存储响应（由304响应元数据更新）为客户端生成200（OK）响应（第4.3.4节）。
If an If-None-Match header field is not present, a request containing an If-Modified-Since header field (Section 3.3 of [RFC7232]) indicates that the client wants to validate one or more of its own stored responses by modification date. A cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) if one of the following cases is true: 1) the selected stored response has a Last-Modified field-value that is earlier than or equal to the conditional timestamp; 2) no Last-Modified field is present in the selected stored response, but it has a Date field-value that is earlier than or equal to the conditional timestamp; or, 3) neither Last-Modified nor Date is
如果不存在If-None-Match标头字段，则包含If-Modified-Since标头字段（RFC7232的第3.3节）的请求表示客户端希望在修改日期之前验证其自己存储的一个或多个响应。如果以下情况之一为真，缓存接收方应生成304（未修改）响应（使用所选存储响应的元数据）：1）所选存储响应具有早于或等于条件时间戳的最后修改字段值；2） 所选存储响应中不存在最后修改的字段，但其日期字段值早于或等于条件时间戳；或者，3）上次修改或日期均不为空
present in the selected stored response, but the cache recorded it as having been received at a time earlier than or equal to the conditional timestamp.
存在于选定的存储响应中，但缓存将其记录为在早于或等于条件时间戳的时间接收到。
A cache that implements partial responses to range requests, as defined in [RFC7233], also needs to evaluate a received If-Range header field (Section 3.2 of [RFC7233]) with respect to its selected stored response.
按照[RFC7233]中的定义，实现对范围请求的部分响应的缓存还需要根据所选存储响应评估接收到的If范围标头字段（第3.2节[RFC7233]）。
Cache handling of a response to a conditional request is dependent upon its status code:
条件请求响应的缓存处理取决于其状态代码：
o A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see Section 4.3.4.
o 304（未修改）响应状态代码表示存储的响应可以更新和重用；见第4.3.4节。
o A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request is suitable. Instead, the cache MUST use the full response to satisfy the request and MAY replace the stored response(s).
o 完整响应（即，具有有效负载主体的响应）表示在条件请求中指定的存储响应中没有一个是合适的。相反，缓存必须使用完整响应来满足请求，并且可以替换存储的响应。
o However, if a cache receives a 5xx (Server Error) response while attempting to validate a response, it can either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, the cache MAY send a previously stored response (see Section 4.2.4).
o 但是，如果缓存在尝试验证响应时收到5xx（服务器错误）响应，则它可以将此响应转发给请求的客户端，或者充当服务器未能响应的角色。在后一种情况下，高速缓存可发送先前存储的响应（见第4.2.4节）。
When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored response(s) with the new information provided in the 304 response.
当高速缓存接收到304（未修改）响应并且已经为同一高速缓存密钥存储了一个或多个200（OK）响应时，高速缓存需要识别哪些存储响应由该新响应更新，然后使用304响应中提供的新信息更新存储响应。
The stored response to update is identified by using the first match (if any) of the following:
存储的更新响应通过使用以下第一个匹配项（如果有）进行标识：
o If the new response contains a strong validator (see Section 2.1 of [RFC7232]), then that strong validator identifies the selected representation for update. All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong validator, then the cache MUST NOT use the new response to update any stored responses.
o 如果新响应包含一个强验证器（请参见[RFC7232]的第2.1节），则该强验证器将标识所选的更新表示。将选择具有相同强验证器的所有存储响应。如果所有存储的响应都不包含相同的强验证器，则缓存不得使用新响应更新任何存储的响应。
o If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then the most recent of those matching stored responses is selected for update.
o 如果新响应包含弱验证器，并且该验证器对应于缓存的一个存储响应，则选择最新的匹配存储响应进行更新。
o If the new response does not include any form of validator (such as in the case where a client generates an If-Modified-Since request from a source other than the Last-Modified response header field), and there is only one stored response, and that stored response also lacks a validator, then that stored response is selected for update.
o 如果新响应不包括任何形式的验证器（例如，客户机从除上次修改的响应头字段之外的源生成If-Modified-Since请求的情况），并且只有一个存储的响应，并且该存储的响应也缺少验证器，则选择该存储的响应进行更新。
If a stored response is selected for update, the cache MUST:
如果选择存储响应进行更新，则缓存必须：
o delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
o 删除存储响应中警告代码为1xx的任何警告标题字段（见第5.5节）；
o retain any Warning header fields in the stored response with warn-code 2xx; and,
o 在存储的响应中保留任何警告标题字段，警告代码为2xx；和
o use other header fields provided in the 304 (Not Modified) response to replace all instances of the corresponding header fields in the stored response.
o 使用304（未修改）响应中提供的其他头字段替换存储响应中相应头字段的所有实例。
A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks a body. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the representation body is not desired even if it has changed.
对HEAD方法的响应与使用GET发出的等效请求相同，只是它缺少主体。如果更有效的条件GET请求机制不可用（由于存储的响应中不存在验证器），或者即使表示体已更改，也不希望传输，则可以使用HEAD响应的此属性来使缓存的GET响应无效或更新。
When a cache makes an inbound HEAD request for a given request target and receives a 200 (OK) response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see Section 4.1).
当缓存对给定的请求目标发出入站头部请求并收到200（OK）响应时，缓存应更新或使其存储的每个GET响应无效，这些GET响应可能已为该请求选择（请参阅第4.1节）。
For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values for any received validator fields (ETag and Last-Modified) and, if the HEAD response has a Content-Length header field, the value of Content-Length matches that of the stored response, the cache SHOULD update the stored response as described below; otherwise, the cache SHOULD consider the stored response to be stale.
对于可能已选择的每个存储响应，如果存储响应和头部响应具有任何接收到的验证器字段（ETag和Last Modified）的匹配值，并且如果头部响应具有内容长度头部字段，则内容长度的值与存储响应的值匹配，缓存应更新存储的响应，如下所述；否则，缓存应该考虑存储的响应是过时的。
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST:
如果缓存使用头响应中提供的元数据更新存储的响应，则缓存必须：
o delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
o 删除存储响应中警告代码为1xx的任何警告标题字段（见第5.5节）；
o retain any Warning header fields in the stored response with warn-code 2xx; and,
o 在存储的响应中保留任何警告标题字段，警告代码为2xx；和
o use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the Cache-Control header field.
o 使用HEAD响应中提供的其他标头字段替换存储响应中相应标头字段的所有实例，并将新标头字段附加到存储响应的标头部分，除非缓存控制标头字段另有限制。
Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them to keep their contents up to date.
由于PUT、POST或DELETE等不安全的请求方法（RFC7231第4.2.1节）可能会改变源服务器上的状态，因此中间缓存可以使用这些方法使其内容保持最新。
A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.
当接收到响应不安全请求方法的非错误状态代码时，缓存必须使有效请求URI（RFC7230）以及位置和内容位置响应标头字段（如果存在）中的URI无效。
However, a cache MUST NOT invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host part in the effective request URI (Section 5.5 of [RFC7230]). This helps prevent denial-of-service attacks.
但是，如果某个位置或内容位置响应头字段中的URI的主机部分与有效请求URI中的主机部分不同，则缓存不得使该URI无效（参见[RFC7230]第5.5节）。这有助于防止拒绝服务攻击。
A cache MUST invalidate the effective request URI (Section 5.5 of [RFC7230]) when it receives a non-error response to a request with a method whose safety is unknown.
当缓存使用安全性未知的方法接收到对请求的非错误响应时，它必须使有效的请求URI（RFC7230的第5.5节）无效。
Here, a "non-error response" is one with a 2xx (Successful) or 3xx (Redirection) status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request.
这里，“非错误响应”是一个带有2xx（成功）或3xx（重定向）状态代码的响应。“Invalidate”表示缓存将删除与有效请求URI相关的所有存储响应，或者将这些响应标记为“invalid”，并且在响应后续请求之前需要进行强制验证。
Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not.
请注意，这并不保证所有适当的响应都无效。例如，状态更改请求可能会使其所经过的缓存中的响应无效，但相关响应仍可能存储在其他尚未存储的缓存中。
This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.
本节定义了与缓存相关的HTTP/1.1头字段的语法和语义。
The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server. Age values are calculated as specified in Section 4.2.3.
“年龄”标题字段表示发件人对自在源服务器上生成或成功验证响应以来的时间量的估计。按照第4.2.3节的规定计算年龄值。
Age = delta-seconds
Age = delta-seconds
The Age field-value is a non-negative integer, representing time in seconds (see Section 1.2.1).
年龄字段值为非负整数，以秒为单位表示时间（见第1.2.1节）。
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age.
年龄标头字段的存在意味着原始服务器没有为此请求生成或验证响应。但是，缺少Age头字段并不意味着联系了源站，因为响应可能是从未实现Age的HTTP/1.0缓存接收的。
The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.
“Cache Control”标头字段用于为请求/响应链上的缓存指定指令。这样的缓存指令是单向的，因为请求中存在指令并不意味着响应中将给出相同的指令。
A cache MUST obey the requirements of the Cache-Control directives defined in this section. See Section 5.2.3 for information about how Cache-Control directives defined elsewhere are handled.
缓存必须遵守本节中定义的缓存控制指令的要求。有关如何处理别处定义的缓存控制指令的信息，请参见第5.2.3节。
Note: Some HTTP/1.0 caches might not implement Cache-Control.
注意：某些HTTP/1.0缓存可能无法实现缓存控制。
A proxy, whether or not it implements a cache, MUST pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
无论代理是否实现缓存，都必须在转发的消息中传递缓存指令，而不管它们对该应用程序的意义如何，因为这些指令可能适用于请求/响应链上的所有收件人。无法将指令定向到特定缓存。
Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both forms, even if one is documented to be preferred. For any directive not defined by this specification, a recipient MUST accept both forms.
缓存指令由令牌标识，不区分大小写进行比较，并且有一个可选参数，该参数可以使用令牌和带引号的字符串语法。对于下面定义的定义参数的指令，接收者应该接受两种形式，即使其中一种形式被记录为首选。对于本规范未定义的任何指令，收件人必须接受两种形式。
Cache-Control = 1#cache-directive
缓存控制=1#缓存指令
cache-directive = token [ "=" ( token / quoted-string ) ]
cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.
对于下面定义的缓存指令，除非另有说明，否则不定义（也不允许）任何参数。
Argument syntax:
参数语法：
delta-seconds (see Section 1.2.1)
增量秒（见第1.2.1节）
The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a stale response.
“max age”请求指令表示客户端不愿意接受期限大于指定秒数的响应。除非还存在max stale request指令，否则客户端不愿意接受过时的响应。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式：例如，“max age=5”而不是“max age=“5”。发送方不应生成带引号的字符串表单。
Argument syntax:
参数语法：
delta-seconds (see Section 1.2.1)
增量秒（见第1.2.1节）
The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
“max stale”请求指令表示客户端愿意接受超过其新鲜度生存期的响应。如果为max stale分配了一个值，则客户端愿意接受超出其新鲜度生存期不超过指定秒数的响应。如果没有为max stale指定值，那么客户机愿意接受任何年龄的stale响应。
This directive uses the token form of the argument syntax: e.g., 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式：例如，“max stale=10”而不是“max stale=”10“。发送方不应生成带引号的字符串表单。
Argument syntax:
参数语法：
delta-seconds (see Section 1.2.1)
增量秒（见第1.2.1节）
The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
“min fresh”请求指令表示客户端愿意接受其新鲜度生存期不小于其当前年龄加上指定时间（以秒为单位）的响应。也就是说，客户机希望响应至少在指定的秒数内保持新鲜。
This directive uses the token form of the argument syntax: e.g., 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式：例如，“min fresh=20”而不是“min fresh=”20“。发送方不应生成带引号的字符串表单。
The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server.
“no cache”请求指令表示，如果未在源服务器上成功验证，缓存不得使用存储的响应来满足请求。
The "no-store" request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
“no store”请求指令指示缓存不能存储此请求或对其的任何响应的任何部分。此指令适用于专用缓存和共享缓存。在此上下文中，“不得存储”意味着缓存不得有意将信息存储在非易失性存储器中，并且必须尽最大努力在转发信息后尽快将其从易失性存储器中删除。
This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
本指令不是确保隐私的可靠或充分机制。特别是，恶意或受损缓存可能无法识别或遵守此指令，并且通信网络可能容易被窃听。
Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already stored response.
请注意，如果缓存满足包含此指令的请求，则no-store-request指令不适用于已存储的响应。
The "no-transform" request directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
“no transform”请求指令指示中介（无论是否实现缓存）不得转换有效负载，如[RFC7230]第5.7.2节所定义。
The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with
“only if cached”请求指令表示客户端只希望获得存储的响应。如果收到此指令，缓存应该使用与请求的其他约束一致的存储响应进行响应，或者使用
a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.
504（网关超时）状态代码。如果一组缓存作为具有良好内部连接的统一系统运行，则成员缓存可在该组缓存内转发此类请求。
The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.
“must revalidate”响应指令指出，一旦响应过时，如果未在源服务器上成功验证，缓存就不能使用响应来满足后续请求。
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
必须重新验证指令对于支持某些协议功能的可靠运行是必要的。在任何情况下，缓存都必须遵守必须重新验证指令；特别是，如果缓存由于任何原因无法到达源服务器，它必须生成504（网关超时）响应。
The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could result in incorrect operation, such as a silently unexecuted financial transaction.
当且仅当未能验证对表示的请求可能导致错误操作（例如未执行的静默金融交易）时，服务器才应使用must revalidate指令。
Argument syntax:
参数语法：
#field-name
#字段名
The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
“no cache”response指令表示，如果未在源服务器上成功验证，则不得将响应用于满足后续请求。这允许源服务器阻止缓存在不与请求联系的情况下使用它来满足请求，即使配置为发送过时响应的缓存也是如此。
If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s) listed MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
如果no cache response指令指定了一个或多个字段名，则缓存可以使用响应来满足后续请求，但需遵守缓存的任何其他限制。但是，如果没有与源服务器成功重新验证，则响应中列出字段名的任何头字段都不得在对后续请求的响应中发送。这允许源服务器防止在响应中重复使用某些头字段，同时仍允许缓存响应的其余部分。
The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
给出的字段名不限于本规范定义的标题字段集。字段名不区分大小写。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
此指令使用参数语法的带引号的字符串形式。发件人不应生成令牌表单（即使单条目列表似乎不需要引用）。
Note: Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented.
注意：尽管它已被移植到许多实现中，但一些HTTP/1.0缓存将无法识别或遵守此指令。此外，带有字段名的no-cache响应指令通常由缓存处理，就像接收到非限定no-cache指令一样；i、 e.对合格表格的特殊处理未得到广泛实施。
The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
“no store”响应指令表示缓存不能存储即时请求或响应的任何部分。此指令适用于专用缓存和共享缓存。在此上下文中，“不得存储”意味着缓存不得有意将信息存储在非易失性存储器中，并且必须尽最大努力在转发信息后尽快将其从易失性存储器中删除。
This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
本指令不是确保隐私的可靠或充分机制。特别是，恶意或受损缓存可能无法识别或遵守此指令，并且通信网络可能容易被窃听。
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230].
“no transform”响应指令指示中介（无论是否实现缓存）不得转换有效负载，如[RFC7230]第5.7.2节所定义。
The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache. (See Section 3.2 for additional details related to the use of public in response to a request containing Authorization, and Section 3 for details of how public affects responses that would normally not be stored, due to their status codes not being defined as cacheable by default; see Section 4.2.2.)
“public”response指令表示任何缓存都可以存储响应，即使响应通常是不可缓存的或只能在私有缓存中缓存。（关于响应包含授权的请求而使用public的更多详细信息，请参见第3.2节；关于public如何影响通常不会存储的响应的详细信息，请参见第3节，因为默认情况下，这些响应的状态代码未定义为可缓存；请参见第4.2.2节。）
Argument syntax:
参数语法：
#field-name
#字段名
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.
“private”response指令表示响应消息是针对单个用户的，不能由共享缓存存储。私有缓存可以存储响应并将其重新用于以后的请求，即使响应通常是不可缓存的。
If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated with the listed response header fields. That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message.
如果private response指令指定了一个或多个字段名，则此要求仅限于与列出的响应标头字段关联的字段值。也就是说，共享缓存不能存储指定的字段名，而可以存储响应消息的其余部分。
The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.
给出的字段名不限于本规范定义的标题字段集。字段名不区分大小写。
This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists).
此指令使用参数语法的带引号的字符串形式。发件人不应生成令牌表单（即使单条目列表似乎不需要引用）。
Note: This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message content. Also, private response directives with field-names are often handled by caches as if an unqualified private directive was received; i.e., the special handling for the qualified form is not widely implemented.
注意：使用“private”一词仅控制响应的存储位置；它无法确保消息内容的隐私。此外，带有字段名的私有响应指令通常由缓存处理，就像接收到非限定的私有指令一样；i、 e.对合格表格的特殊处理未得到广泛实施。
The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.
“proxy revalidate”响应指令与must revalidate响应指令具有相同的含义，只是它不适用于私有缓存。
Argument syntax:
参数语法：
delta-seconds (see Section 1.2.1)
增量秒（见第1.2.1节）
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
“max age”response指令表示响应的期限大于指定的秒数后将被视为过时。
This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式：例如，“max age=5”而不是“max age=“5”。发送方不应生成带引号的字符串表单。
Argument syntax:
参数语法：
delta-seconds (see Section 1.2.1)
增量秒（见第1.2.1节）
The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
“s-maxage”响应指令表示，在共享缓存中，该指令指定的最大使用年限将覆盖max age指令或Expires标头字段指定的最大使用年限。s-maxage指令还暗示了代理重新验证响应指令的语义。
This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the quoted-string form.
此指令使用参数语法的标记形式：例如，“s-maxage=10”而不是“s-maxage=“10”。发送方不应生成带引号的字符串表单。
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional value. A cache MUST ignore unrecognized cache directives.
缓存控制头字段可以通过使用一个或多个缓存扩展令牌进行扩展，每个令牌都有一个可选值。缓存必须忽略无法识别的缓存指令。
Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics of other directives.
可以添加信息扩展（不需要更改缓存行为的扩展），而无需更改其他指令的语义。
Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the old directive are supplied, such that applications that do not understand the new directive will default to the behavior specified by the old directive, and those that understand the new directive will recognize it as modifying the requirements associated with the old directive. In this way, extensions to the existing cache-control directives can be made without breaking deployed caches.
行为扩展被设计为充当现有缓存指令基础的修饰符。同时提供新指令和旧指令，因此不理解新指令的应用程序将默认为旧指令指定的行为，而理解新指令的应用程序将识别为修改与旧指令相关的需求。通过这种方式，可以在不破坏已部署缓存的情况下对现有缓存控制指令进行扩展。
For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive: in addition to private caches, any cache that is shared only by members of the named community is allowed to cache the response. An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including
例如，考虑一个假设为“社区”的假设性新响应指令，它作为私有指令的修饰符：除了私有缓存之外，任何被命名社区成员共享的缓存都允许缓存响应。希望允许UCI社区在其共享缓存中使用其他私有响应的源服务器可以通过包括
Cache-Control: private, community="UCI"
缓存控制：专用，community=“UCI”
A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache that does not recognize the community cache-extension would ignore it and adhere to the private directive.
识别这种社区缓存扩展的缓存可以根据该扩展扩展扩展其行为。不识别社区缓存扩展的缓存将忽略它，并遵守private指令。
The "Expires" header field gives the date/time after which the response is considered stale. See Section 4.2 for further discussion of the freshness model.
“Expires”标题字段给出了响应被视为过时的日期/时间。有关新鲜度模型的进一步讨论，请参见第4.2节。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expires字段的存在并不意味着原始资源将在该时间、之前或之后更改或停止存在。
The Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231].
Expires值是HTTP日期时间戳，如[RFC7231]第7.1.1.1节所定义。
Expires = HTTP-date
Expires = HTTP-date
For example
例如
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
缓存收件人必须将无效的日期格式（尤其是值“0”）解释为表示过去的时间（即“已过期”）。
If a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field.
如果响应包含带有max age指令的缓存控制字段（第5.2.2.8节），则收件人必须忽略Expires字段。同样，如果响应包含s-maxage指令（第5.2.2.9节），则共享缓存收件人必须忽略Expires字段。在这两种情况下，Expires中的值仅适用于尚未实现缓存控制字段的收件人。
An origin server without a clock MUST NOT generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated with the resource by a system or user with a reliable clock.
没有时钟的源服务器不得生成Expires字段，除非其值表示过去的固定时间（始终过期），或者其值已由具有可靠时钟的系统或用户与资源关联。
Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and many caches will evict a response far sooner than that.
历史上，HTTP要求Expires字段值在未来不超过一年。虽然不再禁止更长的新鲜度生命周期，但已经证明，非常大的值会导致问题（例如，由于使用32位整数作为时间值而导致时钟溢出），并且许多缓存会比这更快地退出响应。
The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.
“Pragma”头字段允许与HTTP/1.0缓存向后兼容，以便客户端可以指定一个他们可以理解的“无缓存”请求（因为直到HTTP/1.1才定义缓存控制）。当缓存控制头字段也存在并在请求中被理解时，Pragma将被忽略。
In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates such extensions to improve interoperability.
在HTTP/1.0中，Pragma被定义为一个可扩展字段，用于实现指定的收件人指令。本规范不推荐使用此类扩展来提高互操作性。
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
When the Cache-Control header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1).
当缓存控制头字段不存在于请求中时，缓存必须考虑无缓存请求PrimMA指令，其效果与“缓存控制：没有缓存”相同（见第5.2.1节）。
When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
发送无缓存请求时，客户机应该同时包含pragma和cache-control指令，除非cache-control:no-cache被故意忽略，以HTTP/1.1缓存上的其他缓存控制响应指令为目标。例如：
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response.
将限制HTTP/1.1缓存以提供不超过30秒的响应，同时阻止不了解缓存控制的实现提供缓存响应。
Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.
注意：由于没有指定响应中“Pragma:no cache”的含义，因此它不能可靠地替代响应中的“cache Control:no cache”。
The "Warning" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message.
“Warning”（警告）标题字段用于携带可能未反映在状态代码中的有关消息状态或转换的附加信息。此信息通常用于警告应用于消息有效负载的缓存操作或转换可能导致的不正确。
Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguishes these responses from true failures.
警告可用于其他用途，包括缓存相关用途和其他用途。使用警告，而不是错误状态代码，将这些响应与真正的故障区分开来。
Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only be applied to response messages.
警告标头字段通常可以应用于任何消息，但是某些警告代码特定于缓存，只能应用于响应消息。
Warning = 1#warning-value
警告=1#警告值
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date ]
警告值=警告代码SP警告代理SP警告文本[SP警告日期]
warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding
; the Warning header field, for use in debugging
; a single "-" is recommended when agent unknown
warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE
warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding
; the Warning header field, for use in debugging
; a single "-" is recommended when agent unknown
warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE
Multiple warnings can be generated in a response (either by the origin server or by a cache), including multiple warnings with the same warn-code number that only differ in warn-text.
一个响应中可以生成多个警告（由源服务器或缓存生成），包括多个警告，这些警告具有相同的警告代码编号，但警告文本不同。
A user agent that receives one or more Warning header fields SHOULD inform the user of as many of them as possible, in the order that they appear in the response. Senders that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. A sender that generates new Warning header fields MUST append them after any existing Warning header fields.
接收一个或多个警告标头字段的用户代理应按照这些字段在响应中出现的顺序通知用户尽可能多的警告标头字段。建议生成多个警告标头字段的发件人在订购时牢记此用户代理行为。生成新警告标头字段的发件人必须将其附加到任何现有警告标头字段之后。
Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from a stored response after validation:
警告被分配三位数字的警告代码。第一位数字表示验证后是否需要从存储的响应中删除警告：
o 1xx warn-codes describe the freshness or validation status of the response, and so they MUST be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and MUST NOT be generated in any other situation.
o 1xx警告代码描述响应的新鲜度或验证状态，因此必须在验证后由缓存删除。它们只能在验证缓存项时由缓存生成，在任何其他情况下都不能生成。
o 2xx warn-codes describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression of the representation) and they MUST NOT be deleted by a cache after validation, unless a full response is sent, in which case they MUST be.
o 2xx警告代码描述了未通过验证纠正的表示的某些方面（例如，表示的有损压缩），并且在验证后不得通过缓存删除这些代码，除非发送完整响应，在这种情况下，必须删除这些代码。
If a sender generates one or more 1xx warn-codes in a message to be sent to a recipient known to implement only HTTP/1.0, the sender MUST include in each corresponding warning-value a warn-date that matches the Date header field in the message. For example:
如果发件人在要发送给仅实现HTTP/1.0的收件人的邮件中生成一个或多个1xx警告代码，则发件人必须在每个相应的警告值中包含与邮件中的日期标头字段匹配的警告日期。例如：
HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.
警告附带有描述错误的警告文本，例如用于日志记录的警告文本。它只是建议性的，其内容不影响警告代码的解释。
If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the Date value in the same message, the recipient MUST exclude the warning-value containing that warn-date before storing, forwarding, or using the message. This allows recipients to exclude warning-values that were improperly retained after a cache validation. If all of the warning-values are excluded, the recipient MUST exclude the Warning header field as well.
如果使用、评估或显示警告标头字段的收件人收到的警告日期与同一邮件中的日期值不同，则在存储、转发或使用邮件之前，收件人必须排除包含该警告日期的警告值。这允许收件人排除缓存验证后错误保留的警告值。如果排除了所有警告值，则收件人还必须排除警告标题字段。
The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in Section 7.2.1.
本规范定义了以下警告代码，每个代码都有推荐的英文警告文本及其含义说明。第7.2.1节描述了定义附加警告代码的程序。
A cache SHOULD generate this whenever the sent response is stale.
无论何时发送的响应过时，缓存都应生成此消息。
A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server.
缓存在发送过时响应时应生成此消息，因为由于无法访问服务器，验证响应的尝试失败。
A cache SHOULD generate this if it is intentionally disconnected from the rest of the network for a period of time.
如果缓存故意与网络的其余部分断开连接一段时间，则缓存应生成此消息。
A cache SHOULD generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
如果缓存试探性地选择了大于24小时的新鲜度生存期，并且响应的时间大于24小时，则缓存应该生成此消息。
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.
警告文本可以包括要呈现给用户或记录的任意信息。收到此警告的系统除了向用户显示警告外，不得采取任何自动操作。
This Warning code MUST be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response.
如果代理对表示应用任何转换（如更改内容编码、媒体类型或修改表示数据），则必须添加此警告代码，除非此警告代码已出现在响应中。
The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action.
警告文本可以包括要呈现给用户或记录的任意信息。收到此警告的系统不得采取任何自动操作。
User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.
用户代理通常具有历史记录机制，例如“后退”按钮和历史记录列表，可用于重新显示先前在会话中检索到的表示。
The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.
新鲜度模型（第4.2节）不一定适用于历史机制。也就是说，历史机制可以显示以前的表示，即使它已过期。
This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).
这并不禁止历史机制告诉用户某个视图可能已过时或遵守缓存指令（例如，缓存控制：无存储）。
The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at <http://www.iana.org/assignments/http-cache-directives>.
“超文本传输协议（HTTP）缓存指令注册表”定义缓存指令的命名空间。它已创建，现在维护在<http://www.iana.org/assignments/http-cache-directives>.
A registration MUST include the following fields:
注册必须包括以下字段：
o Cache Directive Name
o 缓存指令名
o Pointer to specification text
o 指向规范文本的指针
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
添加到此命名空间的值需要IETF审查（请参见[RFC5226]，第4.1节）。
New extension directives ought to consider defining:
新的扩展指令应该考虑定义：
o What it means for a directive to be specified multiple times,
o 多次指定指令意味着什么，
o When the directive does not take an argument, what it means when an argument is present,
o 当指令不接受参数时，参数存在时的含义，
o When the directive requires an argument, what it means when it is missing,
o 当指令需要一个参数时，当它丢失时意味着什么，
o Whether the directive is specific to requests, responses, or able to be used in either.
o 指令是否特定于请求、响应，或者是否能够在其中使用。
See also Section 5.2.3.
另见第5.2.3节。
The registry has been populated with the registrations below:
注册表已填充以下注册：
+------------------------+----------------------------------+
| Cache Directive | Reference |
+------------------------+----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.8 |
| max-stale | Section 5.2.1.2 |
| min-fresh | Section 5.2.1.3 |
| must-revalidate | Section 5.2.2.1 |
| no-cache | Section 5.2.1.4, Section 5.2.2.2 |
| no-store | Section 5.2.1.5, Section 5.2.2.3 |
| no-transform | Section 5.2.1.6, Section 5.2.2.4 |
| only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.6 |
| proxy-revalidate | Section 5.2.2.7 |
| public | Section 5.2.2.5 |
| s-maxage | Section 5.2.2.9 |
| stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+----------------------------------+
+------------------------+----------------------------------+
| Cache Directive | Reference |
+------------------------+----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.8 |
| max-stale | Section 5.2.1.2 |
| min-fresh | Section 5.2.1.3 |
| must-revalidate | Section 5.2.2.1 |
| no-cache | Section 5.2.1.4, Section 5.2.2.2 |
| no-store | Section 5.2.1.5, Section 5.2.2.3 |
| no-transform | Section 5.2.1.6, Section 5.2.2.4 |
| only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.6 |
| proxy-revalidate | Section 5.2.2.7 |
| public | Section 5.2.2.5 |
| s-maxage | Section 5.2.2.9 |
| stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+----------------------------------+
The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at <http://www.iana.org/assignments/http-warn-codes>.
“超文本传输协议（HTTP）警告代码”注册表定义警告代码的命名空间。它已创建，现在维护在<http://www.iana.org/assignments/http-warn-codes>.
A registration MUST include the following fields:
注册必须包括以下字段：
o Warn Code (3 digits)
o 警告代码（3位）
o Short Description
o 简短描述
o Pointer to specification text
o 指向规范文本的指针
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
添加到此命名空间的值需要IETF审查（请参见[RFC5226]，第4.1节）。
The registry has been populated with the registrations below:
注册表已填充以下注册：
+-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 5.5.1 |
| 111 | Revalidation Failed | Section 5.5.2 |
| 112 | Disconnected Operation | Section 5.5.3 |
| 113 | Heuristic Expiration | Section 5.5.4 |
| 199 | Miscellaneous Warning | Section 5.5.5 |
| 214 | Transformation Applied | Section 5.5.6 |
| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |
+-----------+----------------------------------+---------------+
+-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 5.5.1 |
| 111 | Revalidation Failed | Section 5.5.2 |
| 112 | Disconnected Operation | Section 5.5.3 |
| 113 | Heuristic Expiration | Section 5.5.4 |
| 199 | Miscellaneous Warning | Section 5.5.5 |
| 214 | Transformation Applied | Section 5.5.6 |
| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |
+-----------+----------------------------------+---------------+
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).
本文档定义了以下HTTP头字段，因此“永久消息头字段名称”注册表已相应更新（请参见[BCP90]）。
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Age | http | standard | Section 5.1 |
| Cache-Control | http | standard | Section 5.2 |
| Expires | http | standard | Section 5.3 |
| Pragma | http | standard | Section 5.4 |
| Warning | http | standard | Section 5.5 |
+-------------------+----------+----------+-------------+
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Age | http | standard | Section 5.1 |
| Cache-Control | http | standard | Section 5.2 |
| Expires | http | standard | Section 5.3 |
| Pragma | http | standard | Section 5.4 |
| Warning | http | standard | Section 5.5 |
+-------------------+----------+----------+-------------+
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 HTTP caching. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
本节旨在告知开发人员、信息提供商和用户HTTP缓存特有的已知安全问题。HTTP消息传递[RFC7230]和语义[RFC7231]中介绍了更一般的安全注意事项。
Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.
缓存暴露了其他潜在漏洞，因为缓存内容是恶意攻击的诱人目标。由于缓存内容在HTTP请求完成后仍然存在，因此在用户认为信息已从网络中删除很久之后，对缓存的攻击可能会泄露信息。因此，缓存内容需要作为敏感信息进行保护。
In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see Section 3.3.3 of [RFC7230] for the relevant requirements.
特别是，存储在共享缓存中可能会放大各种攻击；这种“缓存中毒”攻击使用缓存将恶意负载分发给许多客户端，当攻击者可以使用实现缺陷、提升的权限或其他技术将此类响应插入缓存时，这种攻击尤其有效。一个常见的攻击向量用于缓存中毒是利用差异的消息解析代理服务器和用户代理；相关要求见[RFC7230]第3.3.3节。
Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.
同样，实现缺陷（以及对缓存操作的误解）可能会导致缓存被认为是私有的敏感信息（例如身份验证凭据），从而将其暴露给未经授权的方。
Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache.
此外，缓存的使用也会带来隐私问题。例如，如果两个用户共享一个缓存，而第一个用户浏览某个站点，第二个用户可能能够检测到另一个用户访问过该站点，因为由于缓存，来自该站点的资源加载速度更快。
Note that the Set-Cookie response header field [RFC6265] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.
注意，设置Cookie响应头字段[RFC6265]不禁止缓存；具有Set 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月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：条件请求”，RFC 7232，2014年6月。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，2014年6月。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，2014年6月。
[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月。
[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月。
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.
[RFC5861]诺丁汉，M.，“过时内容的HTTP缓存控制扩展”，RFC 58612010年4月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
The specification has been substantially rewritten for clarity.
为了清晰起见，本规范已被大量重写。
The conditions under which an authenticated response can be cached have been clarified. (Section 3.2)
已经澄清了可以缓存经过身份验证的响应的条件。（第3.2节）
New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (Section 4.2.2)
新的状态代码现在可以定义允许缓存使用启发式新鲜度。缓存现在可以计算带有查询组件的URI的启发式新鲜度。（第4.2.2节）
The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (Section 4.2.3)
计算年龄的算法现在不那么保守了。现在需要缓存来处理带有时区的日期，就好像它们是无效的一样，因为不可能准确地猜测。（第4.2.3节）
The Content-Location response header field is no longer used to determine the appropriate response to use when validating. (Section 4.3)
内容位置响应标头字段不再用于确定验证时要使用的适当响应。（第4.3节）
The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (Section 4.1)
选择要使用的缓存协商响应的算法已通过几种方式阐明。特别是，它现在在处理选择的标题字段时显式地允许特定于标题的规范化。（第4.1节）
Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (Section 4.4)
关于执行失效时避免拒绝服务攻击的要求已经澄清。（第4.4节）
Cache invalidation only occurs when a successful response is received. (Section 4.4)
缓存失效仅在收到成功响应时发生。（第4.4节）
Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (Section 5.2)
缓存指令被明确定义为不区分大小写。现在定义了在只需要一个缓存指令时处理多个缓存指令实例。（第5.2节）
The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (Section 5.2.1.5)
“no store”请求指令不适用于响应；i、 例如，缓存可以满足一个没有存储的请求，并且不会使其失效。（第5.2.1.5节）
The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (Section 5.2.2)
注意到私有和无缓存指令的限定形式没有得到广泛实现；例如，“private=foo”被许多缓存解释为简单的“private”。此外，还阐明了无缓存的限定形式的含义。（第5.2.2节）
The "no-cache" response directive's meaning has been clarified. (Section 5.2.2.2)
“无缓存”响应指令的含义已经澄清。（第5.2.2.2节）
The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. (Section 5.3)
已删除Expires标头字段值的一年限制；相反，给出了使用合理值的理由。（第5.3节）
The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (Section 5.4)
Pragma header字段现在仅为向后兼容而定义；不推荐使用未来的pragma。（第5.4节）
Some requirements regarding production and processing of the Warning header fields have been relaxed, as it is not widely implemented. Furthermore, the Warning header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (Section 5.5)
关于警告标题字段的生成和处理的一些要求已经放宽，因为它没有得到广泛实施。此外，警告标题字段不再使用RFC 2047编码，也不允许使用多种语言，因为这些方面没有实现。（第5.5节）
This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (Section 7.1 and Section 7.2)
本规范介绍了缓存指令和警告代码注册表，并定义了新缓存指令的注意事项。（第7.1节和第7.2节）
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>
field-name = <field-name, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
OWS = <OWS, see [RFC7230], Section 3.2.3>
field-name = <field-name, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
port = <port, see [RFC7230], Section 2.7>
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
uri-host = <uri-host, see [RFC7230], Section 2.7>
port = <port, see [RFC7230], Section 2.7>
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
uri-host = <uri-host, see [RFC7230], Section 2.7>
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节展开。
Age = delta-seconds
Age = delta-seconds
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] )
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] )
Expires = HTTP-date
Expires = HTTP-date
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
OWS = <OWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] )
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] )
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
)
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
)
cache-directive = token [ "=" ( token / quoted-string ) ]
cache-directive = token [ "=" ( token / quoted-string ) ]
delta-seconds = 1*DIGIT
delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ]
extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, see [RFC7230], Section 3.2>
field-name = <field-name, see [RFC7230], Section 3.2>
port = <port, see [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
port = <port, see [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7>
uri-host = <uri-host, see [RFC7230], Section 2.7>
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
]
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
]
Index
指数
1 110 (warn-code) 31 111 (warn-code) 31 112 (warn-code) 31 113 (warn-code) 31 199 (warn-code) 32
1110（警告代码）31111（警告代码）31112（警告代码）31113（警告代码）31199（警告代码）32
2 214 (warn-code) 32 299 (warn-code) 32
2 214（警告代码）32 299（警告代码）32
A age 11 Age header field 21
“年龄11”年龄标题字段21
C cache 4 cache entry 5 cache key 5-6 Cache-Control header field 21
C缓存4缓存条目5缓存键5-6缓存控制头字段21
D Disconnected Operation (warn-text) 31
D断开操作（警告文本）31
E Expires header field 28 explicit expiration time 11
E Expires标头字段28显式过期时间11
F fresh 11 freshness lifetime 11
F新鲜度11新鲜度寿命11
G Grammar Age 21 Cache-Control 22 cache-directive 22 delta-seconds 5 Expires 28 extension-pragma 29 Pragma 29 pragma-directive 29 warn-agent 29 warn-code 29 warn-date 29 warn-text 29
G语法年龄21缓存控制22缓存指令22增量秒5过期28扩展名pragma 29 pragma 29 pragma指令29警告代理29警告代码29警告日期29警告文本29
Warning 29 warning-value 29
警告29警告值29
H Heuristic Expiration (warn-text) 31 heuristic expiration time 11 M max-age (cache directive) 22, 26 max-stale (cache directive) 22 min-fresh (cache directive) 22 Miscellaneous Persistent Warning (warn-text) 32 Miscellaneous Warning (warn-text) 32 must-revalidate (cache directive) 24
H启发式过期（警告文本）31启发式过期时间11 M最大期限（缓存指令）22，26最大过期（缓存指令）22 min新鲜（缓存指令）22杂项持续警告（警告文本）32杂项警告（警告文本）32必须重新验证（缓存指令）24
N no-cache (cache directive) 23, 25 no-store (cache directive) 23, 24 no-transform (cache directive) 23, 25
N无缓存（缓存指令）23、25无存储（缓存指令）23、24无转换（缓存指令）23、25
O only-if-cached (cache directive) 23
O仅当缓存时（缓存指令）23
P Pragma header field 29 private (cache directive) 25 private cache 4 proxy-revalidate (cache directive) 26 public (cache directive) 25
P Pragma头字段29 private（缓存指令）25 private cache 4 proxy revalidate（缓存指令）26 public（缓存指令）25
R Response is Stale (warn-text) 30 Revalidation Failed (warn-text) 31
R响应过时（警告文本）30重新验证失败（警告文本）31
S s-maxage (cache directive) 27 shared cache 4 stale 11 strong validator 18
S-maxage（缓存指令）27共享缓存4过时11强验证程序18
T Transformation Applied (warn-text) 32
已应用T转换（警告文本）32
V validator 16
V验证器16
W Warning header field 29
W警告标题字段29
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/
Mark Nottingham (editor) Akamai
马克·诺丁汉（编辑）Akamai
EMail: mnot@mnot.net
URI: http://www.mnot.net/
EMail: mnot@mnot.net
URI: http://www.mnot.net/
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/