摘要

  • 一个 Cache-Status 成员描述的是报告缓存如何处理对应请求和响应；其中 hit 与 fwd 具有明确的本地含义。
  • 缓存自行决定何时发送该字段，参数可以省略，披露也可能受限，因此较短的成员列表不能证明不存在其他缓存或决定。

设想一项明确属于假设的事故复盘。响应中只有 Cache-Status: edge; hit。仪表盘画出一个绿色节点，宣布整条路径只有这一层缓存，并记录“没有上游系统参与”。这个成员完全可能是真实的：边缘缓存确实用本地已存响应满足了本次请求，没有向前转发。然而，该响应也可能是在此前一次交换中由更靠近源站的缓存提供，而那一级并未发送自己的字段。字段说明的是边缘节点此刻做了什么，不是已存响应形成过程的完整历史。

RFC 9211 为 Cache-Status 规定了一项精确但有限的任务。列表中的每个成员代表处理了请求并选择报告的缓存。多个成员都被保留时，顺序从最靠近源站的缓存排到最靠近用户的缓存。缓存追加成员时，应保留已有值。这些规则让字段成为调试可见缓存链的有用工具。

但规范并不保证列表穷尽所有缓存。缓存可以决定何时添加字段：有的部署对所有响应添加，有的只在配置开启或请求触发调试模式时添加。安全策略还可能要求省略或选择性披露，因为缓存状态、用户活动和键构造信息可能帮助攻击者。一个成员没有出现，只能说明“这里没有报告”，不必然说明“这里没有缓存”。

参数也只陈述局部事实。hit 表示报告缓存没有转发本次请求，而是从缓存取得响应。fwd 表示该缓存把请求朝源站方向转发，并可用 uri-miss、vary-miss、stale 或 request 等原因解释。这些是有价值的运营事实，不应被稀释成不带边界的红绿标签。

局部真实并不等于拓扑完整。fwd-status 表示下一跳服务器返回的状态；下一跳可能是另一个中间节点，而非源站。缓存标识可以是产品名、主机名、地址或生成字符串。可选细节由部署自行解释。缺少配置和观察点上下文时，相同标签不保证是相同角色，不同标签也不能单独证明存在相互独立的基础设施。

时间边界同样重要。Cache-Status 描述对应的这一次请求与响应。一次 hit 并不会说明已存响应何时、通过哪条链被获取，也不证明该对象的历史中源站从未被访问。它也不解释另一项带有不同指令、凭据、Vary 值或新鲜度条件的相邻请求会如何处理。RFC 9111 规定的缓存选择本来就是逐请求进行的。

这一区分能保护事故归因。可见的 fwd=stale; fwd-status=304 可以支持“报告缓存从下一跳收到了 304”这一命题，却不能单独证明下一跳就是源站、所有缓存都报告了自己，或其他观察点发生了同样决定。字段稀疏可能源于路径短，也可能源于披露策略、实现限制，或者几者并存。

应建立“缓存观察收据”。这是本文提出的运营控制，不是 IETF 定义的协议对象。保存字段原始字节，并把它绑定到请求、响应、观察点与时间。逐一记录预期缓存跳点、该请求类别下的字段发送配置、标识映射、披露或隐藏的参数、转发轨迹、下一跳身份和相互印证的日志。遇到空缺时标记为“未知”，不要把沉默改写成不存在。

收据不会取代 Cache-Status，而是让它停留在正确的证据范围内。报告的 hit 仍证明本地命中，报告的转发仍证明该缓存执行了转发。附加记录回答更大的问题：链中哪些节点具备报告能力，哪些实际报告，以及什么独立证据补齐了缺口。

来源