摘要

  • 2010 年 5 月的 RFC 5861 是独立提交的资料性文件，定义了两项互相独立的缓存控制扩展：stale-while-revalidate 允许边核对边送旧答复，stale-if-error 允许在源站出错时限时送旧成功响应。
  • 文件的示例把时间算得很细：max-age=600, stale-while-revalidate=30 是十分钟新鲜期加三十秒缓冲；max-age=600, stale-if-error=1200 可在总年龄 900 秒、源站返回 500 时，交付带 Age: 900 的旧 200。
  • 2022 年 6 月的 RFC 9111 继续要求过期响应有明确许可，并废弃当年用于提示过期状态的 Warning 字段。

旧页面先到，新检查还在路上

缓存保存一份响应，省去每位读者都回源站取同一内容的路程。新鲜期结束后，通常要重新验证副本是否仍然适用。哪怕内容没变，验证也要穿过网络、等待服务器处理。读者明明离缓存很近，却可能为了这个核对多等一轮。

RFC 5861 给发布者一个有限的选择。响应若写 Cache-Control: max-age=600, stale-while-revalidate=30，前 600 秒是新鲜副本，随后 30 秒缓存可先把已经过期的副本交给读者，同时在后台向源站核对。读者得到低延迟，源站仍有机会确认或替换副本。一个操作处理眼前请求，另一个操作追赶内容的新状态。

三十秒不是自动续命。若没有请求在窗口内触发核对，或者核对一直没有结果，窗口结束后的下一次请求须按正常流程等待。冷门页面可能根本享受不到这招。窗口长短与访问密度共同决定有多少读者看见即时答复；发布者则决定自己能容忍修改被旧副本遮住多久。

一个被旧成功盖住的故障

stale-if-error 处理的是另一种时刻。缓存尝试取当前版本，源站那边却发生会导致 500、502、503 或 504 的状况。只要旧副本还在约定的过期上限内，缓存可以拿它回应请求。读者收到的是过去一次成功，不是这次失败的原样展示。

RFC 的例子从 max-age=600, stale-if-error=1200 开始：副本前十分钟新鲜。在总年龄 900 秒时，源站验证产生 500。缓存可以送出先前保存的 200 OK 正文，并附 Age: 900。状态行上的 200 说的是缓存这次交付了什么；Age 则把内容离源站生成或验证已有多久暴露出来。源站的当前失败被限时挡在读者背后。

额外的 1,200 秒从新鲜期结束算起。总年龄超过 1,800 秒后，例子里的错误就必须传给客户端。旧成功不是永远可刷的通行证。对更新缓慢的资料页，二十分钟缓冲可能让故障无声过去；对支付和权限信息，二十分钟的旧状态可能造成比故障更贵的后果。需要多少缓冲，应由最了解内容的发布者决定。

两项扩展不能揉成一句“允许过期”。后台校验对应慢而可能成功的源站；故障兜底对应这次无法取得当前答复的源站。它们有不同的触发条件和时间上限。缓存负责按条件执行，发布者负责划出可承受的旧信息窗口。

旧的警告牌后来被摘掉

2010 年文件按当时规则期待过期响应带非零 Age 和 Warning 字段。RFC 9111 在 2022 年废弃 Warning：它很少生成，也很少真正显示给用户；其他字段如 Age 能说明相关情况。今天检查缓存响应，若只等一个 Warning 字样，可能等的是已经退出规则的路牌。

2022 年标准同时把权限边界说得更严。no-cache、must-revalidate 等适用指令禁止旧答复时，缓存不得照发。其他情况下，要有断连、客户端或源站明确许可、或协议外约定等条件；RFC 5861 的两个扩展属于明确许可的例子。缓存是被授权的中间执行者，不能靠“性能优化”四字擅自决定所有资源可以过期多久。

RFC 5861 本身是独立发表的资料性文献；RFC 9111 是 2022 年的标准轨道缓存规范。后者明确把前者列为可授权旧答复的机制。要数清真实部署，还缺有日期的响应头、缓存配置和故障期间的抓包。两份标准记录已经说明了制度交换：源站授权一个限时的旧事实，缓存用它买速度或连续性，读者承担事实变旧的风险。