5.2.3. Cache-Control 扩展 (Cache Control Extensions)

Cache-Control header field 可以通过使用一个或多个 cache-extension token 来扩展, 每个 token 都有一个 optional value. cache MUST 忽略无法识别的 cache directive.

informational extension (不需要改变 cache behavior 的扩展) 可以在不改变其他 directive semantics 的情况下添加.

behavioral extension 被设计为通过充当现有 cache directive 基础上的 modifier 来工作. 新 directive 和 standard directive 会同时提供, 因而不理解新 directive 的 application 会默认采用 standard directive 指定的 behavior, 而理解新 directive 的 application 会将其识别为对 standard directive 相关 requirement 的修改. 通过这种方式, 可以在不破坏已部署 cache 的情况下扩展 Cache-Control directive.

例如, 考虑一个假设的新 response directive, 名为 "community", 它充当 private directive 的 modifier: 除 private cache 外, 任何仅由命名 community 成员共享的 cache 都被允许缓存该 response. origin server 若希望允许 UCI community 在其 shared cache 中使用原本 private 的 response, 可以包含:

Cache-Control: private, community="UCI"

识别这种 community cache-extension 的 cache 可以按照该 extension 扩展其 behavior. 不识别 community cache-extension 的 cache 会忽略它并遵守 private directive.

5.3. Expires

"Expires" header field 给出 response 被视为 stale 之后的 date/time. 关于 freshness model 的进一步讨论见 Section 4.2.

Expires field 的存在并不意味着 original resource 会在该时间之前, 当时或之后发生变化或停止存在.

Expires field value 是 HTTP-date timestamp, 如 Section 7.1.1.1 of [RFC7231] 所定义.

Expires = HTTP-date

例如:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

cache recipient MUST 将 invalid date format, 特别是 value "0", 解释为表示过去的时间 (即 "already expired").

如果 response 包含带有 max-age directive 的 Cache-Control field (Section 5.2.2.8), recipient MUST 忽略 Expires field. 同样, 如果 response 包含 s-maxage directive (Section 5.2.2.9), shared cache recipient MUST 忽略 Expires field. 在这两种情况下, Expires 中的 value 仅面向尚未实现 Cache-Control field 的 recipient.

没有 clock 的 origin server MUST NOT 生成 Expires field, 除非其 value 表示过去的某个固定时间 (always expired), 或该 value 已由具有可靠 clock 的其他 system 或 person 与 resource 关联.

历史上, HTTP 要求 Expires field value 不超过未来一年. 虽然更长 freshness lifetime 不再被禁止, 但不鼓励使用极大的 value (例如, 超过 9999 年的未来日期), 因为它们可能导致 timestamp parsing 和 arithmetic overflow 问题.

5.4. Pragma

"Pragma" header field 允许与 HTTP/1.0 cache 向后兼容, 使 client 可以指定它们能理解的 "no-cache" request (因为 Cache-Control 直到 HTTP/1.1 才定义). 当 request 中也存在且理解 Cache-Control header field 时, Pragma 会被忽略.

在 HTTP/1.0 中, Pragma 被定义为 extensible field, 用于 recipient 的 implementation-specified directive. 本 specification 废弃将 Pragma 用于除与 HTTP/1.0 deployment 向后兼容之外的任何用途.

Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

当 request 中不存在 Cache-Control header field 时, cache MUST 考虑该 request 的 Pragma header field, 以确定是否存在 "no-cache" directive.

Note: 由于 response 中 "Pragma: no-cache" 的含义未指定, 它不能为 response 中的 "Cache-Control: no-cache" 提供可靠替代. sender SHOULD NOT 在包含 Cache-Control 的 HTTP/1.1 message 中生成 Pragma.