跳到主要内容

4.2. 新鲜度 (Freshness)

fresh response 是 age 尚未超过其 freshness lifetime 的 response. 相反, stale response 是 age 已经超过 freshness lifetime 的 response.

response 的 freshness lifetime 是 origin server 生成该 response 到其 expiration time 之间的时间长度. explicit expiration time 是 origin server 认为 stored response 在该时间之后不能再被 cache 使用, 除非进一步 validation 的时间点. heuristic expiration time 则是在没有 explicit expiration time 可用时由 cache 分配的时间点.

response 的 age 是自其由 origin server 生成, 或成功与 origin server validation 以来经过的时间.

当 response 在 cache 中是 "fresh" 时, 它可以用于满足后续 request, 而无需联系 origin server, 从而提升效率.

确定 freshness 的主要机制是 origin server 使用 Expires header field (Section 5.3) 或 max-age response directive (Section 5.2.2.8) 提供未来的 explicit expiration time. 通常, origin server 会为 response 分配未来的 explicit expiration time, 因为它认为 representation 在到达 expiration time 之前不太可能发生具有语义意义的变化.

如果 origin server 希望强制 cache 对每个 request 都进行 validation, 它可以分配一个过去的 explicit expiration time, 以指示 response 已经 stale. 符合要求的 cache 通常会在为后续 request 重用 stale cached response 之前对其进行 validation (见 Section 4.2.4).

由于 origin server 并不总是提供 explicit expiration time, cache 在某些情况下也被允许使用 heuristic 来确定 expiration time (见 Section 4.2.2).

用于确定 response 是否 fresh 的计算为:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime 在 Section 4.2.1 中定义; current_age 在 Section 4.2.3 中定义.

client 可以在 request 中发送 max-age 或 min-fresh cache directive, 以约束或放宽对应 response 的 freshness 计算 (Section 5.2.1).

计算 freshness 时, 为避免日期解析中的常见问题:

  • 尽管所有日期格式都被指定为区分大小写, cache recipient SHOULD 以不区分大小写的方式匹配 day, week 和 time-zone name.
  • 如果 cache recipient 的内部时间实现的分辨率低于 HTTP-date 的值, recipient MUST 在内部将解析出的 Expires date 表示为等于或早于接收值的最近时间.
  • cache recipient MUST NOT 允许本地时区影响 age 或 expiration time 的计算或比较.
  • cache recipient SHOULD 将带有 GMT 或 UTC 以外 zone abbreviation 的日期视为对 expiration 计算无效.

注意, freshness 只适用于 cache operation; 它不能用来强制 user agent 刷新显示或重新加载 resource. 关于 cache 和 history mechanism 之间区别的说明, 见 Section 6.

最后于 更新