跳到主要内容

4.2.1. 计算新鲜度生命周期 (Calculating Freshness Lifetime)

cache 可以使用以下第一个匹配项来计算 response 的 freshness lifetime, 记作 freshness_lifetime:

  • 如果 cache 是 shared cache 且存在 s-maxage response directive (Section 5.2.2.9), 使用其值, 或
  • 如果存在 max-age response directive (Section 5.2.2.8), 使用其值, 或
  • 如果存在 Expires response header field (Section 5.3), 使用其值减去 Date response header field 的值, 或
  • 否则, response 中不存在 explicit expiration time. 可能适用 heuristic freshness lifetime; 见 Section 4.2.2.

注意, 该计算不受 clock skew 影响, 因为所有信息都来自 origin server.

当某个给定 directive 出现多个值时, 例如两个 Expires header field, 或多个 Cache-Control: max-age directive, 该 directive 的值被视为无效. 鼓励 cache 将 freshness 信息无效的 response 视为 stale.

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

由于 origin server 并不总是提供 explicit expiration time, 当未指定 explicit time 时, cache MAY 分配 heuristic expiration time, 使用借助其他 header field value 的算法, 例如 Last-Modified time, 来估计一个合理的 expiration time. 本规范不提供具体算法, 但会对其结果施加 worst-case constraint.

当 stored response 中存在 explicit expiration time 时, cache MUST NOT 使用 heuristic 来确定 freshness. 由于 Section 3 中的 requirement, 这实际上意味着 heuristic 只能用于没有 explicit freshness 且 status code 被默认定义为可缓存的 response (见 [RFC7231] Section 6.1), 以及那些没有 explicit freshness 但已被标记为显式可缓存的 response, 例如带有 "public" response directive 的 response.

如果 response 具有 Last-Modified header field ([RFC7232] Section 2.2), 鼓励 cache 使用不超过自该时间以来间隔某个比例的 heuristic expiration value. 该比例的典型设置可能是 10%.

当使用 heuristic 计算 freshness lifetime 时, 如果 response 的 current_age 超过 24 小时且尚未存在此类 warning, cache SHOULD 在 response 中生成带有 113 warn-code 的 Warning header field (见 Section 5.5.4).

Note: [RFC2616] Section 13.9 曾禁止 cache 为带有 query component 的 URI, 即包含 "?" 的 URI, 计算 heuristic freshness. 实践中, 这一点并未被广泛实现. 因此, 如果 origin server 希望阻止 caching, 鼓励它发送显式 directive, 例如 Cache-Control: no-cache.