摘要

  • 304 Not Modified 回答的是一个针对所选表示的 HTTP 条件问题，并允许缓存更新已存储的元数据；它不是整条上游依赖链的新鲜度证书。
  • 当缓存结果被用于高影响决策时，运营方还应把验证器证据绑定到生成该表示所使用的数据快照、规则包或依赖版本。

设想一个由数据库快照提供数据的配置端点。缓存携带已有实体标签发送 If-None-Match。源站依据所选表示评估条件，返回 304 Not Modified。网络没有传输新的表示内容，缓存按照协议更新可更新的元数据。随后，运营仪表盘把这个绿色事件翻译成了一个更宽泛的标签：“依赖链已验证”。

协议证据正是在这一步变成了管理幻觉。即使应用使用的数据库快照已经老于业务决策所能接受的界限，304 仍可能是正确响应。HTTP 精确回答了收到的问题；仪表盘却悄悄换了一个问题。

条件判断有明确对象

RFC 9110 用所选表示的实体标签来定义 If-None-Match。对于条件 GET 或 HEAD，当条件为假时，服务器返回 304，而不是原本会携带内容的 200。这个机制之所以有价值，恰恰因为它的含义有限且精确：验证器条件已依照 HTTP 语义针对目标表示完成评估。

因此，304 并不是一个空的 200。它没有内容，却可以携带指导缓存所需的字段；在适用情况下，包括 ETag、Date、Cache-Control、Expires、Content-Location 和 Vary。RFC 9111 随后规定缓存如何识别需要更新的已存储响应。强验证器和弱验证器承担的角色并不完全相同。找到对应响应后，缓存用 304 中相应的字段更新已存储的头字段，同时遵守规范列出的排除条件。

这是一次严谨的表示元数据操作，不是关于所有上游系统状态的声明。

表示有效不等于依赖处于当前状态

实体标签属于源站为表示选择的语义。应用可以根据最终字节、版本号、部署标识或其他实现输入生成它。HTTP 并不要求一个实体标签编码每一条数据库记录、策略包、功能开关、权益源或上游 API 结果的版本。

当表示由多个依赖派生而来时，这个差别十分关键。JSON 字节自缓存以来可能确实没有变化，因此 304 完全正确。但如果这些字节源自一个本应在五分钟前更新却没有更新的快照，未变化的表示恰恰保留了运营方需要发现的陈旧状态。重新验证确认的是验证器边界内的连续性，它不会事后扩大该边界。

这不是对条件请求的否定。它们节省带宽与计算，也并非每个 304 都隐藏着陈旧数据。问题在于证据范围。“所选表示仍匹配该验证器”不能在没有补充证明时变成“所有依赖均为当前状态”。

补上缺失的谱系

高影响配置响应可以暴露或记录依赖快照标识、源数据更新时间、策略包版本或物化水位。缓存侧则可以保留请求目标、已存储响应身份、条件字段、304 元数据以及实际消费该结果的决策。

这里提出的验证链收据是编辑层面的控制综合，并非 IETF 或所引 RFC 定义的协议对象。它至少应绑定：

  • 请求目标与所选表示身份；
  • 验证器类型和值，以及条件请求字段；
  • 304 的响应时间、状态与返回元数据；
  • 被更新的已存储响应及其字段；
  • 生成表示时使用的上游快照、规则或依赖版本；
  • 依赖该缓存结果的决策、控制或自动化。

如果源站无法把表示绑定到依赖版本，诚实的状态应是“表示已重新验证；依赖是否处于当前状态未知”。它比绿色徽章表达得更窄，却更有助于正确决策。

来源