RFC7234: Hypertext Transfer Protocol (HTTP/1.1): Caching

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

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

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

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

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.

本规范使用了扩展巴科斯范式Augmented Backus-Naur Form（ABNF）标记法【RFC5234】，另外，出于定义的紧凑性的考虑，本规范对 ABNF 规则进行了扩展（见章节 7），允许使用一个 # 操作符（类似于 * 操作符，指代“重复”）来定义一种以逗号分隔的列表。附录 B 描述了从其他文档中引进的规则。附录 C 展示了所有已收集的包含列表扩展规则以及标准 ABNF 标记的语法。

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.

在连接被关闭之前，所有由消息分帧message framing（【RFC7230】）所表明的字节octets都已被接收到，那么，这个响应消息被认为是完整的complete。如果请求方法是 GET，响应状态码是 200 (OK)，并且整个响应头部response header section都已经被接收到，那么，缓存 可以 存储一个不完整incomplete的响应消息体response message body，如果对应的缓存条目是被记录为不完整的话。同样，一个 206 (Partial Content) 响应 可以 被缓存作为一个不完整的 200 (OK) 的缓存条目。但是，如果缓存并不支持 Range 和 Content-Range 头字段，或者它并不理解用在这些头字段中的范围单位range unit，那么，缓存 禁止 存储不完整incomplete的或者部分内容partial-content的响应。

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.

缓存 可以 通过发起后续范围请求range request（【RFC7233】）并将成功响应successful response和已存储的条目进行结合，来使一个已存储的不完整响应补充完整，正如章节 3.3 所定义的。缓存 禁止 使用一个不完整响应来回应请求，除非这个响应已被补充完整，或者这个请求是一个部分请求partial request并指定了一个范围且这个范围统统在该不完整响应以内。对于没有明确地使用 206 (Partial Content) 状态码进行标记的部分响应partial response，缓存 禁止 发送这种部分响应partial response到一个客户端。

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.

如果共享缓存所缓存的一个响应的 key 对应于一个带有 Authorization 头字段（【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.

在本规范中，以下 Cache-Control 响应指令（章节 5.2.2）有上述这种影响：must-revalidate、public、以及 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.

需要注意的是，如果已缓存的响应包含有 must-revalidate 并且/或者 s-maxage 响应指令，那么，这些缓存响应是不允许被共享缓存用来提供陈旧响应serve stale的（章节 4.2.4）。实践中，一个响应，如果它带有 max-age=0, must-revalidate，或者带有 s-maxage=0，那么，在没有经过源服务器重新验证revalidating的情况下，它是不能用来满足后续请求的。

译注：所谓 "serve stale"，指的是：提供陈旧的缓存响应来作为响应，即使这个已缓存的响应已经过期。对于一个请求，当对应的已缓存的响应已经过期（stale），并且源服务器无响应或者响应一个错误，这时候，缓存服务器返回这个 stale 的响应来作为回应，而不是返回错误。在大多数情况下，与其响应超时或返回其他错误，倒不如返回给用户一个能用的但过期的响应。

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

如果连接被过早地关闭了，或者请求使用了一个或多个 Range 规格，那么，一个响应可能只传输一个表示形式的一部分（【RFC7233】）。历经多次这样的传输以后，缓存可能已接收到同一个表示形式的许多范围。缓存 可以 将这些范围合并为单个已存储的响应，并复用这个响应来满足接下来的请求，如果这些请求都共享同一个强验证器，并且缓存遵从【RFC7233】章节 4.3 对于客户端方面的要求的话。

When combining the new response with one or more stored responses, a cache MUST:

• delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
• retain any Warning header fields in the stored response with warn-code 2xx; and,
• 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.

当将一个或多个已存储的响应结合成一个新的响应的时候，缓存 必须 对这个新响应做如下处理：

• 删除在已存储的响应里警告码为 1xx 的任何 Warning 头字段（见章节 5.5）；
• 保留在已存储的响应里警告码为 2xx 的任何 Warning 头字段；并且
• 使用新响应所提供的其他头字段，除以 Content-Range 以外，来替换所有在已存储的响应中对应的头字段。

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 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 头字段（【RFC7231】章节 7.1.4）的响应来满足，那么，它 禁止 使用这种响应，除非所有由 Vary 头字段所指定的选择头字段selecting header fields既与原始请求（即这个已存储响应所关联的那个请求）相匹配，也与所面临的请求相匹配。

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:

• adding or removing whitespace, where allowed in the header field's syntax
• combining multiple header fields with the same field name (see Section 3.2 of [RFC7230])
• 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)

来自这两个请求的选择头字段selecting header fields是定义为相互匹配的，当且仅当在第一个请求的选择头字段，通过应用以下任何方式，能够转换为在第二个请求的选择头字段：

• 在头字段的句法所允许的位置添加或删除空白
• 合并多个相同字段名称的头字段（【RFC7230】章节 3.2）
• 依据头字段的规范，使用已知是具有同等语义的方式，来规范化两者的头字段值（比如，将头字段的值进行重新排序reordering，如果它的顺序并不重要的话；对于值是定义为不区分大小写的地方进行大小写规范化case-normalization）。

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.

带有匹配上的选择头字段selecting header fields的已存储响应，被称为已选响应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.

如果有多个可用的已选响应（可能包括没有 Vary 头字段的响应），缓存将需要选择一个来使用。当一个选择头字段有已知的机制用于做这种选择的时候（比如，Accept 上的 qvalue 以及类似的请求头字段），这种机制 可以 被用来选择最优响应（可能多个）preferred responses。选择好最优响应以后，使用时间最近的那一个响应，见章节 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.

新鲜的响应fresh response，是日期还没超过它的保鲜期freshness lifetime的一种响应。相反，陈旧的响应stale response，是日期已经超过它的保鲜期的一种响应。

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是从它被源服务器生成开始到它的过期时间expiration time之间的时间长度。明确过期时间explicit expiration time，是源服务器打算让一个已存储的响应，在没有进一步的验证的情况下，不再能够被缓存所使用的那个时间点。与之相对，启发式过期时间heuristic expiration time，是当没有可用的明确过期时间explicit expiration time的时候由缓存所指派的过期时间。

译注：明确过期时间explicit expiration time与启发式过期时间heuristic expiration time都是专业术语，下文会多次引用这两个术语。

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.

确定新鲜度的主要机制是源服务器提供一个未来的明确过期时间explicit expiration time，可以使用 Expires 头字段（章节 5.3）来提供，也可以使用 max-age 响应指令（章节 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).

如果源服务器希望强制让缓存每一次请求都要向源服务器进行验证，那么，它可以指派一个过去的明确过期时间explicit expiration time，来表明这个响应已经是陈旧的stale。遵从规范的缓存将会在复用一个陈旧的已缓存的响应来满足后续请求之前，正常地验证它（见章节 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).

因为源服务器并不总是会提供明确过期时间explicit expiration time的，因此，在某种情况下，规范还允许缓存使用启发式方法heuristic来确定一个过期时间（章节 4.2.2）。

The calculation to determine if a response is fresh is:

确定一个响应是否新鲜fresh的计算方法为：

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.

freshness_lifetime 定义在章节 4.2.1，current_age 定义在章节 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 缓存指令来限制或放松对应响应的新鲜度计算（章节 5.2.1）。

When calculating freshness, to avoid common problems in date parsing:

• Although all date formats are specified to be case-sensitive, a cache recipient SHOULD match day, week, and time-zone names case-insensitively.
• 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.
• A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
• A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.

当计算新鲜度的时候，为了避免日期解析的常见问题：

• 虽然所有日期格式都被指定为区分大小写case-sensitive，但是，缓存接收端cache recipient 应当 使用不区分大小写case-insensitive的方式来匹配日day、周week、以及时区time-zone的名称。
• 如果缓存接收端关于时间的内部实现的精度低于 HTTP-date 的值的精度，那么，接收端 必须 以早于或等于所接收到的值的最接近的时间来内部表示一个解析过的 Expires。
• 缓存接收端 禁止 允许本地时区来影响年龄或过期时间age or expiration time的计算或对比。
• 缓存接收端 应当 将一个带有时区缩写不是 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.

需要注意的是，新鲜度仅适用于缓存操作，它并不能被用于强制一个用户代理去刷新refresh它的展示或者重新加载reload一个资源。关于缓存与历史记录的机制的不同点的解释，见章节 6。

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，当缓存已经存储了这个 URI 对应的一个或多个响应，但缓存却不能使用它们之中的任何一个来满足这个请求（比如，因为它们都不再新鲜，或者没有一个可以选择的，见章节 4.1），这时候，缓存在转发这个请求时可以应用条件请求conditional request的机制【RFC7232】，给下一个入站服务器inbound server一个机会来选择一个有效的已存储的响应来使用，在这个过程中会更新已存储的元数据；或者使用一个新的响应到替换（可能是多个）已存储的响应。这个过程称为对已存储的响应进行“验证validating”或者“重新验证revalidating”。

译注：所谓“入站”，即数据流朝向源服务器流动，见【RFC7230】章节 2.3。

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.

当响应中带有一个非错误的状态码non-error status code，而这个响应是回应给一个不安全的请求方法的，那么，缓存 必须 失效invalidate实际请求 URIeffective Request URI（【RFC7230】章节 5.5）以及在 Location 和 Content-Location 响应头字段（如果有出现的话）中的 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.

但是，如果 Location 或者 Content-Location 响应头字段中的 URI 的 host 部分不同于有效请求 URI（【RFC7230】章节 5.5）中的 host 部分的话，缓存 禁止 失效这种 URI。这样做有助于避免拒绝服务攻击denial-of-service attacks。

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.

当缓存接收到一个非错误的回应non-error response，而这个响应是回应给一个请求方法的安全性是未知的请求的，那么，缓存 必须 失效有效请求 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 (Successful) 或 3xx (Redirection) 的响应。所述“失效invalidate”，意味着缓存将会这样做：要么移除该有效请求 URI 相关的所有已存储的响应，要么将这些已存储的响应标记为“无效invalid”并且在它们可以用来响应给后续请求之前需要强制的验证mandatory validation。

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.

需要注意的是这样做并不保证所有合适的响应都会被失效。例如，一个会改变状态的请求可能会将它所途经的缓存中的响应置为失效，但存储在其他缓存中的相关响应仍然未被失效。

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.

Age 头字段运载了发送端的估算时长，该估算时长是从该响应被源服务器生成generated或成功验证successfully validated到现在所持续的时长。章节 4.2.3 指出了 Age 字段值的计算方法。

Age = delta-seconds

The Age field-value is a non-negative integer, representing time in seconds (see Section 1.2.1).

Age 的字段值是一个非负整数，以秒为单位来表示时间（章节 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 缓存，而 HTTP/1.0 缓存并没有实现 Age。

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.

缓存 必须 遵守本章节所定义的 Cache-Control 指令的要求。关于如何处理在别处（非本规范）定义的 Cache-Control 指令，见章节 5.2.3。

Note: Some HTTP/1.0 caches might not implement Cache-Control.

注意： 某些 HTTP/1.0 缓存可能没有实现 Cache-Control。

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.

缓存指令由一个 token 所标识，不区分大小写，它可以带有一个可选的实参argument，这个实参既可以使用 token 句法来表示，也可以使用 quoted-string 来表示。对于下文所定义的指令中有定义实参的，接收端应该能够同时接受这两种实参形式，即使其中一种形式是被注明为首选的。对于其他任何非本规范所定义的指令，接收端 必须 能够同时接受这两种实参形式。

Cache-Control   = 1#cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

For the cache directives defined below, no argument is defined (nor allowed) unless stated otherwise.

对于下文所定义的指令中，除非另有说明，没有定义（也不允许有）实参。

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-date 时间戳，其定义见【RFC7231】章节 7.1.1.1。

Expires = HTTP-date

For example

例如：

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.

如果响应包含有一个 Cache-Control 字段，这个字段带有一个 max-age 指令（章节 5.2.2.8），那么，接收端 必须 忽略 Expires 字段。同样，如果响应包含有一个 s-maxage 指令（章节 5.2.2.9），那么，共享缓存接收端 必须 忽略 Expires 字段。在上述两种情况中，Expires 里的值是仅为还未实现 Cache-Control 字段的那些接收端而设的。

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 的缓存保持向后兼容，以便客户端能够指定一个它们能够理解的 "no-cache" 请求（因为直到 HTTP/1.1 Cache-Control 才被定义出来）。当请求中还出现了 Cache-Control 头字段且被接收端所理解，那么，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 是一个没有确定语义的字段，在不同的实现中可能有所不同。

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

当请求中没有出现 Cache-Control 头字段，那么，缓存 必须 将 Pragma 的 no-cache 指令的效果视同为与 "Cache-Control: no-cache" 一致（见章节 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:

当发送一个 no-cache 请求，客户端应该既包含 Pragma 也包含 Cache-Control 指令，除非有意忽略 Cache-Control: no-cache 而对 HTTP/1.1 缓存使用其他 Cache-Control 响应指令。例如：

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 秒的响应，而阻止并不理解 Cache-Control 的实现去供应一个已缓存的响应。

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 能够用于其他目的，可以是缓存相关的，也可以是其他方面。使用 Warning 而不是错误状态码，其区别是这些响应是否是真正的错误。

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 头字段通常可以应用到任何消息中，然而，某些 warn-code （警告码）是专门用于缓存方面的，并且仅能应用于响应消息。

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

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.

在一个响应中可以生成多个 Warning （要么由源服务器生成，要么由某个缓存生成），包括具有同一个 warn-code 的多个警告而只有在 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.

当用户代理接收到一个或多个 Warning 头字段时，应当 尽可能将它们都告知给用户，按它们出现在响应中的顺序。发送端在生成多个 Warning 头字段时最好按照用户代理的行为习惯来对它们进行排序。发送端在生成新的 Warning 头字段的时候，必须 将它附加到任何已存在的 Warning 头字段之后。

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:

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

Warning 的 warn-code 是一个 3 位数字。第一位数字表明这个 Warning 是否必须在验证以后从已存储的响应中删除：

• 1xx 的 warn-code 描述了响应的新鲜度或验证的状态，因此它们 必须 在验证以后被缓存所删除。它们仅可以在验证一个已缓存的条目的时候由缓存所生成，并且 禁止 在其他任何情况下生成它们。
• 2xx 的 warn-code 描述了在验证之后不会被修复矫正的表示形式的某些方面（例如，表示形式的一个有损压缩），并且缓存在验证以后 禁止 删除它们，除非发送一个完整的响应（这时候就 必须 删除它们了）。

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:

如果发送端在一个消息中生成了一个或多个 1xx 警告码，而它知道这个消息是发往一个只实现了 HTTP/1.0 的接收端的，那么，发送端 必须 在每一个对应的 warning-value 中包含一个与消息中的 Date 头字段相匹配的 warn-date，例如：

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.

Warning 中附带的 warn-text 描述了错误，又如，为了日志记录。它仅供参考，其内容并不会影响到 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.

如果某些 Warning 头字段中的 warn-date 不同于同一个消息中的 Date 字段值，那么，接收端在使用、求值、或者展示这些 Warning 头字段的时候，必须 在存储、转发、或者使用这个消息之前，排除掉所有包含那个 warn-date 的 warning-value。这样使得接收端可以排除掉那些在缓存验证以后不恰当保留下来的 warning-value。如果排除了所有的 warning-value，那么，接收端 必须 连同 Warning 头字段一起排除掉。

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.

本规范定义了下列 warn-code，每个都有一个推荐的英文 warn-text，以及一段描述它的含义的文字。定义额外的警告码的手续在章节 7.2.1 中有所描述。

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。

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。

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】）。

The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

主管以上条目的变更的是 "IETF (iesg@ietf.org) - Internet Engineering Task Force"。

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.

[RFC7230]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014.

[RFC7231]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014.

[RFC7232]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, June 2014.

[RFC7233]

Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, RFC 7233, June 2014.

[RFC7235]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, June 2014.

[BCP90]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

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

[RFC5226]

Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC5861]

Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”, RFC 5861, April 2010.

[RFC5905]

Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, June 2010.

[RFC6265]

Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011.