摘要

  • HTTP Vary 会列出可能影响源站选择响应表示的请求字段；缓存若不向源站重新验证，就必须先确认这些字段与最初存储响应时一致。
  • Vary 不会证明实际部署采用了预期缓存键，也不会证明应用的全部选择条件、租户或授权边界，以及最终送出的响应字节都正确。

设想一个共享边缘节点用同一个 URI 分发各租户的配置。租户 A 请求资源后，源站返回带有 A 品牌信息的内容，并写入 Vary: Accept-Encoding。保障看板检测到合法的 Vary 字段，便把“缓存隔离”标成绿色。随后，租户 B 以相同的内容编码偏好访问同一 URI，却从边缘节点取得了 A 的字节。

这不是 Vary 自身失效。它准确表达了源站为该响应声明的选择维度。真正的问题，是把有限的协议声明误当成它从未承诺提供的、更广泛的隔离证明。

Vary 实际表达什么

RFC 9110 将 Vary 定义为一个响应字段：除请求方法和目标 URI 外，它描述请求中哪些部分可能影响源站选择此次响应内容。字段值若列出若干请求字段名，这些名称就是“选择字段”。这里的措辞很关键：它是源站针对一次响应所作的选择输入声明。

Vary 有两个协议用途。第一，除非之后的请求在被点名字段上匹配，或者源站重新验证了复用行为，否则缓存不能用这份响应满足后续请求。第二，它告诉用户代理，这份响应经过内容协商；改变列出的请求值，可能得到另一种表示。这两个用途都不会让 Vary 变成缓存后来如何存储或交付对象的遥测记录。

通配符进一步划清边界。Vary: * 表示命名字段之外的因素也可能参与选择，例如客户端网络地址。接收方无法只凭后续请求字段判断原响应是否合适，必须把请求转发到源站；代理不得生成这个通配符。它表达的是无法通过普通字段匹配来判定，而不是一个万能的隔离开关。

实际缓存键是另一项事实

RFC 9111 把缓存键定义为缓存选择已存储响应时使用的信息。它至少包含请求方法和目标 URI；缓存可以加入 Vary 点名的请求字段，也可以加入其他材料。

已存响应带有 Vary 时，缓存若要在不重新验证的情况下复用它，所有被点名请求字段都必须与最初触发存储的请求匹配。只有在字段规范认定语义等价时，才可以对空白、大小写或顺序做规范化。被点名字段在原请求中缺失时，只能与后续请求中的同样缺失匹配。包含 Vary: * 的已存响应永远不能匹配。

这些约束非常明确，却没有回答四个运行问题：部署中的缓存是否真的解析并执行了 Vary？中间节点是否删除或改写了它？应用是否使用了未被点名的条件，例如认证后才解析出的租户上下文？送出的对象是否确实就是缓存自认为选中的那个变体？Vary 与这些问题有关，却不是答案本身。

隔离可能依赖报文之外的维度

应用常依据认证账户、租户映射、功能分组、策略版本、司法管辖规则或边缘配置版本来选择内容。有些事实体现在请求字段中，有些来自服务器端状态。RFC 9110 允许在报文语法之外的因素参与选择时使用 Vary: *，但其效果是阻止普通复用，而不是描述一个可重复使用的私有分区。

因此，运营方不能从“存在 Vary”推断租户隔离，也不能从只列出语言和编码的 Vary 推断隔离。语法完全正确的字段，仍可能遗漏应用真实选择逻辑中的维度。反过来，缓存也可能在 Vary 之外增加以隐私为目的的分区。仅看响应无法知道两种情况中的任何一种。

这也与新鲜度问题不同。变体可以仍然新鲜，却因缓存键遗漏维度而属于错误租户；它也可能已经陈旧，但分区本身正确。重新验证能确认某份表示是否可以依据 HTTP 验证器继续使用，却不能证明请求进入了正确的租户分区。新鲜度、验证、授权与变体选择相互关联，但不是同一个控制点。

足以支撑结论的证据

要声称某项部署维持了表示隔离，必须把协议声明与缓存的实际动作连接起来。记录应包含：缓存实例或发布分组及其配置版本；方法和目标 URI；该缓存实际收到的 Vary 值；每个被点名字段的规范化值与缺失状态；应用用于选择内容的所有维度；决策时的租户与授权上下文；命中、未命中或重新验证决定；已存对象身份；以及最终交付字节的摘要。

这里提出的“变体选择收据”是编辑层的证据综合方案，并非 IETF 定义的协议元素。它的作用是防止团队把范围很窄的标准信号提升成更宽泛的运行保障结论。收据还应保留观察点，因为源站、中间缓存和边缘节点看到的字段及采用的配置可能不同。

只要尊重其边界，Vary 就很有价值：它让源站声明的内容协商条件可见，也给合规缓存提供了具体匹配义务。保障错误始于把声明当成实现、隔离或结果的证明。响应头可以写出预期选择维度；只有把实际配置与交付证据连接起来，才能证明正确的表示留在正确的边界内。

来源