摘要

  • HTTP 103 携带的是“很可能”出现在最终应答里的头字段。浏览器可以据此提前请求 preload 资源，但临时字段既不能替代最终字段，也不能改变最终应答的处理。
  • 发提示、做投机、决定导航结果与交付目标资源分别属于不同主体。任何一环提速，都不会自动取得下一环的授权。

一次导航已经到达应用。页面骨架大致确定，数据库结果却可能让请求以 200 页面、302 登录跳转或 500 错误收场。边缘缓存记得昨天的页面引用了 shell.css。若等最终应答，信息最可靠，却会错过一个往返时间；若直接把样式表当成既定事实，又可能为一页根本不会出现的文档浪费流量。

RFC 8297 设计的不是“提前的最终应答”，而是一种刻意较弱的表达。服务器可先送出 103 Early Hints，其中放置 Link: </shell.css>; rel=preload; as=style，然后继续计算最终状态和头字段。支持该机制的浏览器可在等待期间开始获取资源。

Hints 不是修辞，而是权限边界。发送者只说某个字段大概率稍后出现，没有宣告请求成功，没有保证资源会被使用，也没有承诺最终应答一定重复它。客户端得到的是在真相完成前行动的机会，不是把猜测当真相的命令。

一个请求可以收到多段消息，但只有一个最终结果

RFC 9110 把 103 放入 1xx 信息性应答。一次请求可先收到零个或多个临时应答，之后才有一个最终应答。1xx 在头部结束，不带正文或尾部字段。客户端必须能解析临时应答，用户代理则可以忽略未预期的 1xx。

这套结构把“提前利用信息”和“改写请求含义”分开。RFC 8297 允许客户端为性能目的评估 103 字段，却明确要求这种评估不得影响最终应答的正常处理。后来的 200、302、404 或 500 才回答原请求发生了什么。

103 还可以是不完整的。未出现某个字段，不能解释为该字段在最终应答里也不会出现。服务器当时也许只知道一个资源，不知道最终 CSP、缓存策略或更多 Link。若把沉默当成否定承诺，就会让不完整消息获得它本来没有的权力。

早期字段与最终字段也可以不一致。RFC 8297 的例子里，服务器连续送出多条 103，最终保留部分 Link、替换另一条。这并不违反协议；恰好说明为什么必须把这条消息称作提示。

同一条时间线上的四个决定者

源站拥有最终应答。它可以提前透露一部分字段，但仍须对完整状态码、头部和正文负责。缓存中间层也可能成为提示来源：RFC 8297 明确举例，中间层可从旧缓存应答的头字段生成 103，同时等待重验证，再转发源站自己的临时和最终应答。

用户代理拥有投机决定。它可以忽略 103、从缓存满足请求、限制字节、把资源排在更重要工作之后，或在跳转后放弃复用。提示描述一个候选关系，不能越过客户端队列直接占用带宽。

最终应答拥有导航结果。跨站跳转可以把页面带去别处，错误应答可以让预想文档根本不存在，新的 Link 集合可以让早期下载变成闲置。提示无权否决这些结果。

被提示资源还拥有自己的交付事实。DNS、连接、TLS 身份、凭据、缓存命中、响应状态、内容类型与完整性检查，决定是否得到可用对象。一个 URL 出现在 Link 里，不等于它背后的字节已经可信。

RFC 8288 对 Web Linking 的定义正好保持克制：Link 由上下文、关系类型、目标与可选属性构成。它说明资源之间的关系，不认证目标，也不保证解引用成功。

浏览器把宽泛提示收缩为本地规则

现行 HTML 标准 进一步限定了导航中的处理。浏览器可在最终文档应答到来前投机加载资源；当前算法只处理导航中的第一条 Early Hint，若之后发生跨源跳转，则丢弃它。

这个阶段只处理一组有限属性：as、crossorigin、integrity 与 type。一些需要 Document 已建立的属性只能晚些再解释。Early Hint 中的 Link 比最终应答 Link 和文档内 <link> 更早进入处理，不代表它比后两者更有权威。

安全策略也可能提前生效。Early Hint 可携带 Content Security Policy，浏览器据此约束投机请求；最终应答若给出更严格策略，已经下载的响应仍可能不能交给文档使用。流量已经发生，使用权却不会追随流量自动出现。

Fetch 标准 保持同一结构：遇到被处理的 103，就调用 Early Hints 步骤，然后继续等待最终应答。优化位于一次请求生命周期内部，并未替代它。

旧知识可以有价值，但不能冒充当前事实

缓存中间层最能暴露这个机制的治理难题。昨天的页面引用 shell.css，这一事实在重验证完成前可能仍是很好的预测；也可能已经过时，因为应用现在跳转、资源换名，或个性化状态选择了另一套文件。

“过期”不等于毫无用处，“提示”则把它的权限限制在与新鲜度相称的位置。边缘节点提出预测，客户端决定成本，源站完成答案。任何一方的速度都不能吞并另一方的判断。

因此可观测性必须保留来源。运维者要知道 103 来自应用、边缘规则还是旧缓存元数据；要分别保存早期字段与最终字段。若多个层都能发提示，重复和冲突不能被日志压平为一句“服务器发了 preload”。

含义是临时的，网络成本却可能无法撤回

错误提示通常不会让最终页面语义错误，却能产生真实代价。投机请求会暴露对某个目标的兴趣，唤醒第三方服务，消耗移动设备电量，占用连接与拥塞窗口，并与主文档竞争。最终应答到来后，已经发送的包无法“退回”。

所以关键指标不是 103 数量，而是有用的早期工作。要证明客户端确实收到提示、比原本更早开始请求、拿到或复用了响应，并最终让文档消费它。同时记录未使用资源的请求数、字节数、连接占用和第三方负载。

兼容性也必须用运行证据证明。RFC 8297 警告，HTTP/1.1 客户端若把 103 误当最终应答，可能错误划分持久连接上的后续消息，甚至造成跨源信息泄露。因此服务器可在不知道客户端是否正确处理信息性应答时避免通过 HTTP/1.1 发送 103。HTTP/2 的帧边界降低这项特定风险，却不保证提示一定正确或有收益。

IANA HTTP 状态码注册表 证明代码 103 对应 Early Hints，并指向 RFC 8297。注册消除了共同代码点的歧义，不能证明中间层会转发、浏览器会执行、资源会复用或用户会更快看到页面。

Heng Lu 提出的最小初始规范、本地未来决定与自愿采用在这里非常具体：共同层只需说明这是一组临时字段，最终应答仍将到来；是否投机、如何分配资源留给运行代码的参与者。运行代码优先则要求从线上消息、客户端动作与最终用户结果逐层验证，而不是把配置开关当成效果。

一条能被安全关闭的 103 才保持了应有的薄度。忽略提示的客户端仍应得到完整正确的最终应答。若关闭 103 就让页面损坏，优化已经越权，变成未声明的运行依赖。