摘要

  • 103 Early Hints 传递的是对最终响应头的预测，而不是最终响应的提前副本。它可以触发可撤销、损失有上限的准备工作，例如预取资源；最终响应仍可删除、替换或新增字段。
  • 安全采用的关键不是“相信 103”，而是由客户端本地规定投机预算、来源边界与禁区。早期提示不等于认证、授权、同意、缓存结论，也不能为不可逆操作制造许可。

Early Hints 最有价值的时刻，恰好是服务器还不知道完整答案的时刻。

应用也许已经判断某个样式表大概率会进入页面，但仍在等待数据库查询；边缘节点也许记得上一次响应里的链接，但源站正在重新验证；渲染程序也许已能给出第一批依赖，却还无法确定最终状态码。此时发送 103 Early Hints，客户端便可提前发起一项资源获取。

如果所有字段都必须百分之百确定，服务器等到最终响应再发即可。103 所购买的时间，来自它公开承认的不确定性。因此，越想利用这个时间优势，越不能把提示升格为裁决。

HTTP 把“先知道一点”写进了消息顺序

RFC 9110 规定，一次请求可以先收到零个、一个或多个 1xx 临时响应，随后收到一个非 1xx 的最终响应。临时响应在字段区结束，没有内容，也没有尾部字段。客户端即使没有预料到 1xx，也必须具备解析能力；用户代理则可以忽略意外收到的 1xx。

103 位于这条序列的前半段。它表达的是：服务器“很可能”在最终响应中发送这些字段。通常，服务器会在最终响应里重复它们；但如果后续处理发现早先的判断不正确或已经不合适，也可以不重复，或者改成别的值。

RFC 8297 对此给出两条硬边界。第一，早期字段只是提示，不能替代最终响应的字段。第二，除了性能优化之外，对这些字段的评估不得改变最终响应的处理方式。客户端也不能把这些字段当成 103 自身的元数据。

标准中的连续示例尤其重要。服务器先后发送两个 103，合计预告三个 Link；最终响应保留其中两个，把另一个换成新值。这不是协议失信，而是协议在展示自己的本性：它允许随着计算推进而修正预测。

因此，内部系统不宜把收到的字段立刻合并成一个名为“暂定最终响应”的对象。这个名称会诱使下游以为它只差最后盖章。更准确的做法，是按顺序保存每个临时字段块，记录各自触发了什么，等最终响应到达后再核对。

没有出现，也不构成否定

服务器可以只预告它预计会出现的一部分字段。它还可以随着新信息到来发送多个 103，无须在每次消息里重复之前的字段。客户端可以综合这些提示，但不能因为某个字段没出现，就推断最终响应也不大可能出现它。

这是容易被忽略的单向性。103 可以说“这个资源可能有用”，却没有用沉默表达“其他资源一定无用”。如果早期消息没有缓存指令、安全字段或认证质询，客户端不能据此放宽最终处理。

这种设计也避免把优化通道变成承诺通道。要求服务器提前列全所有最终字段，就等于要求它先完成决策，随后才允许预告；那样会把速度收益抹掉。共同规范只定义了如何表达一组正向、局部、可修正的判断。

真正需要在本地回答的问题不是“103 靠不靠谱”，而是“判断错了会损失什么”。一次可取消的公开静态资源获取，与一次库存锁定、付款、账户变更或敏感信息外发，错误成本完全不同。字段相同，也不能抹平效果差异。

preload 是关系类型，不是远程命令

RFC 8297 的典型例子使用 Link 响应头和 preload 关系。Web Linking 为链接关系提供共同语义：目标与当前上下文之间存在某种声明的关系。能够理解 preload 的客户端，可以认为提前获取目标可能有助于随后处理最终表示。

“可以”是核心。关系类型没有强迫所有接收者采取同一动作。设备可以因为流量昂贵而忽略；浏览器可以只允许特定资源类别；企业客户端可以禁止跨源预取；安全策略可以限制凭据与请求模式。共同语义让各方看懂提示，本地政策决定是否花钱。

预取并不是无成本的思想实验。它会消耗带宽、占用连接、触达目标服务、影响缓存，并可能泄露客户端对某个地址的兴趣。若平台规则允许携带凭据，还会带来更高敏感度。字段提前到达，不会暂停同源、认证、授权、凭据、内容类型或大小限制。

即使下载成功，也不能反推最终响应的语义。最终结果可能是错误、重定向或认证质询；预告的链接也可能被删除。资源已经在本地，不表示页面必须使用它，更不表示客户端获得了执行或展示它的许可。

合理原则是：103 只能提前启动原本就独立获准的工作，不能由自己生成那份许可。时间可以前移，权力不应跟着前移。

中间节点让来源判断更复杂

客户端看到的第一个 103，不一定来自最终响应的生成者。RFC 8297 描述了一种缓存中间节点：它根据陈旧缓存响应里的字段先生成一个 103；随后在重新验证期间，再转发源站发送的 103 和最终响应。

这正是边缘计算的优势——离用户更近的节点利用历史信息抢时间。但历史信息不是当前事实，中间节点也不是源站的替身。一个早期链接被收到，只能证明链路上某个获准发出或转发消息的组件提供了这一预测，不能单独证明源应用刚刚认可它。

RFC 9110 一般要求代理转发 1xx，除非相关临时响应是代理自己请求生成的。转发义务保证消息能通过链路，却不会给转发者或字段增加最终语义权威。

现实部署中，CDN、网关和应用团队应说清：哪一层可以合成 103，依据哪份缓存，允许多旧，源站的新提示如何覆盖边缘预测，错误命中如何计量。客户端未必能从线上消息复原完整作者链，所以它只能对“来源仍有歧义”时也安全的动作开放预算。

监测数据也不应把所有 103 都归为“服务器说的”。否则，边缘节点长期输出陈旧链接，会被误诊为应用反复改变主意。

把临时响应误当最终响应，会破坏消息边界

RFC 8297 的安全章节特别讨论 HTTP/1.1。某些客户端可能把 103 误当作最终响应。在持久连接上，它随后可能把后续请求的响应也归入前一个消息。如果同一连接复用了不同源的请求，这种错位可能造成跨源信息泄露。

可见，“临时”不仅是给人看的语气词，也是协议的结构状态。RFC 9112 要求客户端把收到的响应消息关联到第一个尚未取得最终非 1xx 响应的待处理请求。一个请求在结束前可以经过多个信息响应。状态机一旦走错，字节属于谁也会跟着走错。

RFC 8297 因而提出：在 HTTP/1.1 上，如果不知道客户端能否正确处理信息响应，服务器可以选择不发送 103。文档认为 HTTP/2 较不容易遭遇这一特定的分帧错误，因为临时响应的字段块属于明确的流，带信息状态码的字段块不能结束该流。HTTP/3 同样允许一个或多个 1xx 先于最终响应，并明确临时响应没有内容和尾部字段。

更清晰的传输分帧只能解决一类问题。HTTP/3 客户端仍可能在完整解析后，把预测当作同意或授权。线协议负责守住消息边界，应用政策负责守住行为边界，两者不能互相代替。

缓存记住的是过去，不是当前裁决

缓存型中间节点之所以能更早提示，是因为它保留了旧响应的知识。旧知识可能高度准确，却天然存在过期可能。昨天的页面需要某个脚本，今天的页面也许已经不需要；重新验证可能返回新版本，也可能返回完全不同的状态。

RFC 9111 把缓存的新鲜度、验证、存储与复用分别定义。由 103 触发的获取，不会自行决定最终响应可否缓存、是否新鲜、是否适用于当前请求。某个文件被提前放入缓存，也不等于最终页面承诺引用它。

运营指标至少应区分五件事：提示已发出、客户端已识别、获取已开始、最终字段已确认、资源实际被使用。只看首屏速度，会掩盖预测错误的成本：丢弃字节、重复请求、连接压力、隐私暴露以及额外的源站负载。

各方激励并不一致。站点希望更快渲染，用户承担无用流量，边缘节点希望提高缓存利用率，源站却可能承受额外请求。把投机预算交给实际承担成本的客户端，是避免一方把优化代价外包给另一方的基本治理安排。

小型共同规范，容纳多种本地选择

IANA 的 HTTP 状态码登记表把 103 登记为 Early Hints，并指向 RFC 8297。该文档于 2017 年作为 IETF 实验性协议发布，经过社区共识、公开审查和 IESG 批准，但不属于标准轨道。采用时必须保留这一成熟度事实，不能把它描述成全球强制部署规则。

它提供的共同层很小：一个明确的临时状态、普通 HTTP 字段、位于最终响应之前的顺序，以及不得替代最终字段的边界。小到这种程度，反而让不同参与者可以在不失去互操作性的前提下作不同决定。

资源受限的客户端可以全部忽略；浏览器可以只处理熟悉的链接关系；企业环境可以禁用跨源投机；缓存可以只在近期命中率足够高时合成提示。它们都理解同一个消息，却不必购买同一种风险。

这与卢恒提出的“最小初始规范—未来决策本地化—知情自愿采用”一致。服务器掌握当前计算进度，中间节点掌握自身缓存质量，客户端掌握网络价格、设备资源和安全策略。未来动作留在能观察后果的一端，而不是交给每次请求都要请示的中央机构。

不设中央许可办公室，不等于没有约束。约束应提前落在本地：允许哪些关系类型、哪些源、哪些凭据模式、多少流量，以及哪些效果永远不得由早期字段启动。这样既保留低延迟，也保留责任边界。

建立投机账本，而不是影子响应

成熟实现首先把每个 103 和最终响应分开保存，并保持顺序。日志应能回答：哪个字段块触发了哪个请求，使用什么 HTTP 版本，由哪个可见中间角色转发，适用哪条本地政策。

其次，它按效果分类。可取消、公开、大小受限的获取可以进入投机预算；修改状态、转移价值、泄露新信息、建立同意或改变访问权的操作必须等待独立授权与最终证据。

最终响应到达后，系统进行核对，而不是改写历史：哪些提示得到重复，哪些消失，哪些被替换；哪些准备仍有用，哪些应取消；节省了多少时间，浪费了多少资源。最终字段决定响应处理，预测记录只用于解释性能与风险。

最后，系统必须始终保留“忽略”的能力。RFC 9110 允许用户代理忽略意外的 1xx。某个网络、版本或中间节点变得不安全时，客户端可以停止基于 103 行动，同时继续正确处理最终响应。

Early Hints 的价值不在于提前知道未来，而在于诚实地标记“不完整”。协调系统可以借鉴这条纪律：早点共享足以支持可逆准备的信息，把错误损失限制在本地，然后让收集完事实的决定保留最终权威。

来源