5.2.3. 缓存控制扩展 (Cache Control Extensions)

Cache-Control 头字段可以通过使用一个或多个缓存扩展令牌来扩展，每个令牌都有一个可选值。缓存必须忽略无法识别的缓存指令。

信息性扩展（不需要更改缓存行为的扩展）可以在不更改其他指令语义的情况下添加。

行为扩展旨在通过充当现有缓存指令基础的修饰符来工作。新指令和标准指令都被提供，因此不理解新指令的应用程序将默认使用标准指令指定的行为，而理解新指令的应用程序将识别它正在修改与标准指令相关的要求。通过这种方式，可以在不破坏已部署缓存的情况下对 Cache-Control 指令进行扩展。

例如，考虑一个假设的新响应指令，称为 "community"，它充当 private 指令的修饰符：除了私有缓存之外，仅由命名社区的成员共享的任何缓存都被允许缓存响应。希望允许 UCI 社区在其共享缓存中使用原本私有的响应的源服务器可以通过包含以下内容来实现：

Cache-Control: private, community="UCI"

识别此类 community 缓存扩展的缓存可以根据该扩展扩大其行为。不识别 community 缓存扩展的缓存将忽略它并遵守 private 指令。

5.3. 过期时间 (Expires)

"Expires" 头字段给出了响应被视为过期的日期/时间。有关新鲜度模型的进一步讨论，请参见第 4.2 节。

Expires 字段的存在并不意味着原始资源将在该时间之前、当时或之后更改或停止存在。

Expires 字段值是 HTTP 日期时间戳，如 [RFC7231] 的第 7.1.1.1 节所定义。

Expires = HTTP-date

例如：

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

缓存接收方必须将无效的日期格式（特别是值 "0"）解释为表示过去的时间（即 "已经过期"）。

如果响应包含带有 max-age 指令的 Cache-Control 字段（第 5.2.2.8 节），则接收方必须忽略 Expires 字段。同样，如果响应包含 s-maxage 指令（第 5.2.2.9 节），则共享缓存接收方必须忽略 Expires 字段。在这两种情况下，Expires 中的值仅用于尚未实现 Cache-Control 字段的接收方。

没有时钟的源服务器不得生成 Expires 字段，除非其值表示过去的固定时间（始终过期）或其值已由具有可靠时钟的某个其他系统或人员与资源关联。

从历史上看，HTTP 要求 Expires 字段值不超过未来一年。虽然不再禁止更长的新鲜度生命周期，但不鼓励使用极大的值（例如，超过 9999 年的未来日期），因为它们可能导致时间戳解析和算术溢出问题。

5.4. 编译指示 (Pragma)

"Pragma" 头字段允许与 HTTP/1.0 缓存向后兼容，以便客户端可以指定它们将理解的 "no-cache" 请求（因为 Cache-Control 直到 HTTP/1.1 才定义）。当请求中还存在并理解 Cache-Control 头字段时，Pragma 将被忽略。

在 HTTP/1.0 中，Pragma 被定义为用于接收方实现指定指令的可扩展字段。本规范不推荐将 Pragma 用于除与 HTTP/1.0 部署向后兼容以外的任何用途。

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

当请求中不存在 Cache-Control 头字段时，缓存必须考虑请求的 Pragma 头字段以确定是否存在 "no-cache" 指令。

注意：因为响应中 "Pragma: no-cache" 的含义未指定，所以它不能为响应中的 "Cache-Control: no-cache" 提供可靠的替代。发送方不应该在包含 Cache-Control 的 HTTP/1.1 消息中生成 Pragma。