摘要

  • 103 Early Hints 是信息性响应，允许客户端在服务器仍生成最终响应时进行推测性准备。
  • 提示字段可能与最终响应不同，最终状态也可能是成功、重定向、客户端错误或服务器错误。
  • preload 链接只描述与目标资源的关系，并不证明获取会成功，也不证明请求者获得授权。
  • 监控系统必须保存完整响应链和每个推测请求的结果，才能把 Early Hints 与真实可用性联系起来。

设想一个交付看板只记录它看到的第一个状态。边缘节点返回带有两个 preload 链接的 103 Early Hints，看板立即变绿。片刻后，同一请求以 503 Service Unavailable 结束，其中一个提前请求的资源也失败了。103 是真实而且可能有用的；“服务已就绪”的判断却并不成立。

RFC 8297 定义 Early Hints，是为了利用服务器生成最终响应时原本被浪费的等待时间。客户端可以据此提前建立连接，或请求很可能需要的样式表。它的价值正来自“不等确定结果就开始准备”。

规范使用的是“很可能”出现在最终响应中的字段，而不是“必定”。通常服务器会在最终响应中重复这些字段，但也可能在后续处理里发现早期判断错误或已经不合适，因此删去或更改它们。只保存 103 的测量会抹掉协议刻意保留的不确定性。

RFC 8297 还明确指出，103 中的字段不能取代最终响应字段。除性能优化以外，提前处理不应改变客户端对最终响应的处理方式。preload 可以开始准备，但访问控制、内容选择、缓存规则和最终状态仍由完成后的响应及其背后的系统决定。

RFC 9110 给出了完整的消息模型：一次请求可以先收到零个或多个 1xx 临时响应，随后收到一个非 1xx 的最终响应。各类状态码含义不同：1xx 表示过程信息，2xx 表示成功，3xx 表示重定向，4xx 表示客户端错误条件，5xx 表示服务器错误。把 103 记成成功，等于把有顺序的状态过程压成了一个过早的布尔值。

最终响应是必要证据，但有时仍不足以代表用户结果。一个 200 文档可能引用稍后加载失败、完整性校验不通过、被策略阻止或到达太晚的资源。匿名探针与已登录会话也可能取得不同内容。响应链必须继续关联到运营者真正关心的业务结果。

RFC 8288 把 Web Link 定义为上下文资源与目标资源之间的类型化关系。带 preload 关系的 Link 字段可以告诉客户端可能的目标及处理方式，但它不保证 DNS 解析、连接建立、TLS 验证、授权、缓存资格、对象完整性或下载成功。

观察位置同样不可省略。浏览器、CDN、反向代理或合成探针看到 103，只能证明这个观察者在这次交换里收到了信息性响应。它不能单独说明每个字段究竟由哪一跳产生，也不能保证另一地区、另一 HTTP 版本、另一缓存状态或另一身份会看到相同序列。

推测也有成本。错误预取会占用连接、带宽、终端电量和缓存。RFC 8297 对提前处理字段作出限制，正因为性能优化也可能带来安全与隐私影响。正确做法不是关闭 Early Hints，而是把它的范围、代价和结果分开记录。

一份 HTTP 响应链收据应包含请求方法与目标、协议与连接标识、观察位置，以及按顺序排列的全部信息性状态和字段；还应记录最终状态、最终字段，并在可行时保存最终表示的散列。每个推测目标都要关联关系类型、触发它的 103、凭证模式、缓存结果、最终状态、完整性结果和耗时。中间层或缓存身份、授权上下文与观察时间也必须入账，但不应保存秘密。

这样，看板就能诚实地区分“观察到 103”“启动预取”“收到最终 200”“验证表示”“完成应用交易”。这些事件可以同屏展示，却不能由第一项自动制造后四项。

这种分离也改善故障定位。如果 103 更快而最终响应更慢，问题可能在较晚的应用处理。如果只有一个边缘位置的提示资源失败，问题可能属于路径、缓存或部署。如果最终 Link 集合改变，可能发生了较晚的路由、内容或授权决定。不同现象需要不同责任人。

在正确边界内，Early Hints 是有价值的证据：它说明被观察的 HTTP 链已经进入可以传递暂定关系的阶段，也能揭示浪费的推测、较慢的源站工作和边缘差异。它不能做的，是承诺尚未到来的最终响应。

来源

RFC 8297 — An HTTP Status Code for Indicating Hints; RFC 9110 — HTTP Semantics; RFC 8288 — Web Linking.