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
        
1. Introduction
1. 介绍

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节),则该响应仍可以重用。

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

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节定义了与错误处理相关的一致性标准和注意事项。

1.2. Syntax Notation
1.2. 语法符号

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表示法。

1.2.1. Delta Seconds
1.2.1. 增量秒

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年),不需要以二进制形式存储;如果发生任何溢出,即使使用无法直接表示该数字的算术类型执行计算,实现也可以将其生成为屏蔽字符串。这里重要的是检测溢出,而不是在以后的计算中将其视为负值。

2. Overview of Cache Operation
2. 缓存操作概述

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节)。

3. Storing Responses in Caches
3. 将响应存储在缓存中

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.

请注意,在正常操作中,某些缓存不会存储既没有缓存验证器也没有显式过期时间的响应,因为这样的响应通常不会用于存储。但是,缓存并不禁止存储此类响应。

3.1. Storing Incomplete Responses
3.1. 存储不完整的响应

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(部分内容)状态代码明确标记的情况下,不得向客户端发送部分响应。

3.2. Storing Responses to Authenticated Requests
3.2. 存储对经过身份验证的请求的响应

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”的响应不能用于满足后续请求,而必须在源服务器上重新验证它。

3.3. Combining Partial Content
3.3. 合并部分内容

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 使用新响应中提供的其他头字段(内容范围除外)替换存储响应中相应头字段的所有实例。

4. Constructing Responses from Caches
4. 从缓存构造响应

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.

没有可用时钟的缓存在每次使用时都必须重新验证存储的响应,才能使用存储的响应。

4.1. Calculating Secondary Keys with Vary
4.1. 使用变量计算辅助关键字

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节)请求的形式转发到源服务器。

4.2. Freshness
4.2. 新鲜度

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节。

4.2.1. Calculating Freshness Lifetime
4.2.1. 计算新鲜度寿命

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指令),该指令的值被视为无效。高速缓存被鼓励考虑具有无效新鲜度信息的响应是陈旧的。

4.2.2. Calculating Heuristic Freshness
4.2.2. 计算启发式新鲜度

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)。在实践中,这并没有得到广泛实施。因此,如果源服务器希望排除缓存,则鼓励它们发送显式指令(例如,缓存控制:无缓存)。

4.2.3. Calculating Age
4.2.3. 计算年龄

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;
        
4.2.4. Serving Stale Responses
4.2.4. 提供陈腐的回应

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.

在转发没有年龄标头字段的响应时,缓存不应生成新的警告标头字段,即使该响应已过时。缓存不需要验证仅在传输过程中过时的响应。

4.3. Validation
4.3. 验证

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],为下一个入站服务器提供选择要使用的有效存储响应的机会,更新进程中存储的元数据,或用新响应替换存储的响应。此过程称为“验证”或“重新验证”存储的响应。

4.3.1. Sending a Validation Request
4.3.1. 发送验证请求

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标头字段中(即,客户使用列出的实体标记专门指代一个或多个先前获得的表示)。

4.3.2. Handling a Received Validation Request
4.3.2. 处理收到的验证请求

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

4.3.3. Handling a Validation Response
4.3.3. 处理验证响应

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节)。

4.3.4. Freshening Stored Responses upon Validation
4.3.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(未修改)响应中提供的其他头字段替换存储响应中相应头字段的所有实例。

4.3.5. Freshening Responses via HEAD
4.3.5. 通过头部刷新响应

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响应中提供的其他标头字段替换存储响应中相应标头字段的所有实例,并将新标头字段附加到存储响应的标头部分,除非缓存控制标头字段另有限制。

4.4. Invalidation
4.4. 无效

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.

请注意,这并不保证所有适当的响应都无效。例如,状态更改请求可能会使其所经过的缓存中的响应无效,但相关响应仍可能存储在其他尚未存储的缓存中。

5. Header Field Definitions
5. 标题域定义

This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.

本节定义了与缓存相关的HTTP/1.1头字段的语法和语义。

5.1. Age
5.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.

“年龄”标题字段表示发件人对自在源服务器上生成或成功验证响应以来的时间量的