摘要

  • HTTPbis 于 2026 年 9 月 9 日发布 draft-ietf-httpbis-pre-denied-01。它是有效的工作组草案，不是 RFC，也不代表 419 已获 IANA 分配。
  • 新版把“Preliminary Request Denied”改为 Purpose Declined，提出 419，并把范围扩大到基于 Sec-Purpose 所声明用途的拒绝。Fetch 当前只定义了 prefetch 这一取值。
  • 草案允许源站及代表源站行事的网关返回该响应；独立代理不应返回。关键不是谁能生成报文，而是谁有权表达源站策略。
  • 419 只标示拒绝类型，并不披露具体规则。我建议保存一份最小用途决定记录，绑定声明、决策者、授权、策略版本、时间、缓存处理和结果。这是 Daniel Kade 的编辑建议，不是草案要求。

01 版真正改变的是决策归属

表面上的新闻是一个数字。9 月 9 日 08:56 UTC，Datatracker 发布 The Purpose Declined HTTP Status Code 01 版，把 00 版里的通用 4xx 占位符换成拟议的 419。旧标题针对“预备请求”，正文主要谈预取与预加载；新版改为：若服务器因请求在 Sec-Purpose 中声明的用途而拒绝它，就可以给出“Purpose Declined”。

数字尚未成为标准事实。Datatracker 显示，这是一份 HTTPbis 工作组文档，属于 IETF stream，预期走 Proposed Standard，document shepherd 为 Tommy Pauly。但 IESG 状态仍是 I-D Exists，没有负责的 Area Director、IESG 处理阶段或 telechat。IANA 的现行 HTTP 状态码注册表仍将 419-420 标为未分配。

比数字更重要的是新加入的主体规则。源站可以生成该响应；CDN、反向代理等网关在代表源站行事时也可以生成；独立代理则不应这样做。这不是在描述设备能力。任何能截断连接的中间节点在技术上都可能拼出一个 4xx。草案限制的是语义权力：谁可以把自己的拒绝呈现为源站的用途策略。

因此，“位于源站之前”不是授权证明。网关的资格来自委托关系，而不是拓扑位置。独立传输代理能够看到 Sec-Purpose，也可能有节流、安全或成本动机，却不能据此自动继承应用所有者的政策声音。

声明用途不等于证明动机

Fetch Standard 给 Sec-Purpose 的任务很窄：表明一次请求服务于即时使用之外的用途。它是结构化请求头；截至本文截点，唯一已定义的 token 是 prefetch。服务端可以据此调整缓存期限、拒绝预取，或以不同方式统计访问。

“Purpose Declined”这个名称比“Preliminary Request Denied”更能容纳将来的 token，但名称不会凭空创造 token。它也没有赋予服务器新能力。服务器本来就可以拒绝请求；新响应只是把“因所声明用途而拒绝”变成客户端和运营人员可识别的一类结果。

可识别不等于已证实。Sec-Purpose: prefetch 记录的是客户端怎么描述这次请求，不是用户内心的真实目的，不证明后台加载获得了同意，也不指明到底哪个软件模块触发了访问。反过来，419 也不公开服务端策略：某站可能拒绝全部预取，另一站只在高负载、特定区域、特定内容或异常信号下拒绝。

协议交换最多支持两项判断：请求方声明了一个用途；具有权限的服务端主体以该用途为依据作出拒绝。若把它升级为对流量合法性、用户意愿或客户端诚信的总判决，便超出了报文能够提供的证据。

“代表源站”需要可核验的委托

在边缘架构中，策略所有者与实际回应者经常不是同一组件。CDN 可以在请求抵达应用之前结束连接并执行租户规则；反向代理也能在应用外层拦截访问。这样做节省带宽与计算资源，却会在排障时留下一个基本问题：究竟是谁决定了拒绝？

状态行回答不了这个问题。运营者需要知道：是源站应用自己判断，还是网关执行明确委托的规则，抑或是管理上独立的中间节点自行干预？哪个源站或租户授予了权限？当时使用哪个策略版本？例外条件是否被评估？

答案不应是把私有规则塞进公开响应。草案的安全部分已经提醒，按用途拒绝可能泄露服务器内部状态；越详细的公开理由，泄露面越大。更合适的做法是在受控运营系统中保存一个与响应对应的最小记录：精确的 Sec-Purpose token、决策组件及其角色、所代表的源站或租户、稳定的策略标识与版本、决定时间、响应结果、发送的缓存处理，以及在安全范围内可披露的原因类别。

这不是要求记录用户画像，也不是建立通用访问档案。它只保留复现争议决定、验证网关授权所必需的字段。网络距离再近，也不能替代委托关系的证据。

禁止缓存是在限制决定的外溢

01 版要求响应内容长度为零，并建议接收端丢弃任何实际收到的内容；它还说明 419 不可启发式缓存，而且不应被缓存。这些限制决定了某一次拒绝能传播多远、持续多久。

RFC 9110 为未知代码保留了兼容路径：不认识 419 的客户端仍应把它当作同类的 x00，也就是通用 4xx。RFC 9111 则给出 HTTP 存储的一般规则。草案单独写下更严格的“不应缓存”，是为了避免某个时刻、负载或策略版本下的用途拒绝被当成长期答案重复播放。

当网关负责决策时，错误缓存会进一步模糊权力来源。拒绝可能跨过租户边界，延续到策略已经更新之后，或应用在一个用途不同的新请求上。此时 419 看似仍在代表源站，实际上源站从未作出后一次决定。把缓存处理同决策者、授权和策略版本一起记录，才能让这种漂移可见。

合理的分工是：线上报文只提供最小共同语义，内部记录承担可审计性，本地披露政策决定哪些理由可以安全地告诉请求方。

来源