摘要

  • draft-ietf-httpbis-pre-denied-01 提议用 419 表示服务端因请求在 Sec-Purpose 中声明的用途而拒绝该次请求；这项说明只适用于关联请求，相同用途的未来请求可能成功，也可能失败。
  • 419 峰值可以证明分类响应增加，却不能单独证明源站故障、永久访问规则、真人意图或未来不可用。自动化必须保留生成节点、缓存路径和普通导航的独立回执。

凌晨的告警没有读协议文本。它只读到四百多个 4xx，于是把“预取被拒绝”改写成“访问策略大面积失败”，把事件等级升到最高，并建议封锁发起请求的客户端群体。

但这些请求不是认证失败，也不是用户访问被拒。浏览器把它们标记为推测性预取；代表源站执行策略的边缘节点认为发送完整表示没有收益，于是拒绝了这些请求。随后发生的正常导航仍然成功。告警准确数出了响应，却错误地创造了事件。

《The Purpose Declined HTTP Status Code》01 版于 2026 年 9 月 9 日作为 IETF HTTP 工作组的活跃 Internet-Draft 发布，预定在 2027 年 3 月 13 日到期，目标是标准轨道。它仍是可能修改、替换或失效的工作文件。冻结证据时，IANA HTTP 状态码注册表尚未分配 419。因此本文讨论的是提案及其证据边界，不是 RFC、正式注册、部署普及度或互操作结论。

状态码让理由更清楚，不让权力自动成立

草案的出发点是推测性请求。Fetch 标准允许用户代理通过 Sec-Purpose 表达请求用途，例如 prefetch。服务端可能知道，发送完整响应不会改善性能，反而会增加成本或造成其他负面影响。

如果用 503 表达这种决定，运维人员容易把它理解为过载或计划维护导致的暂时不可用。RFC 9110 对 503 的描述正与这类运行故障有关。草案试图给“因为声明用途而拒绝”一个更窄的分类，从而避免污染故障指标。

这个分类没有创造新的拒绝能力。源站和获得委托的网关原本就能拒绝请求。状态码只规定如何说明理由。它不授予无关代理替源站做决定的权力，也不证明实际实现诚实地采用了这个理由。

因此，一条合格记录不能只有 status=419。它还要有方法、目标、收到的 Sec-Purpose、时间、连接、生成节点、该节点是否代表源站、缓存状态、策略版本与关联标识。代码是证据的一部分，不是全部权力链。

告警系统也在行使分类权

协议生产者声明“此次请求因用途被拒绝”；监控平台决定把它放进哪个指标；事件系统又决定指标触发什么动作。这三层权力经常被当成同一件事。

如果平台把全部 4xx 计入访问故障，新的语义被立即丢掉。如果平台完全忽略 419，过度拒绝预取造成的延迟和源站压力又可能消失。正确方法不是选择红色或绿色，而是建立不同分母。

服务可用性回答系统能否处理请求。用途拒绝率回答某一类请求受到何种策略。后续导航结果回答用户最终看到什么。一次响应可以把三张表关联起来，却不能把三种结论压成一个数字。

这也是衡量改版是否有效的方式。503 数量下降，可能只是旧事件被重新命名，并不证明容量提升。419 数量增加，也可能是更准确的观测，而不是新故障。需要比较用户结果与决策归因，不能只比较颜色。

声明用途不是身份、授权或真人意图

Sec-Purpose 表达的是用户代理赋予请求的上下文。浏览器可能根据自己的预测规则触发预取，用户不一定点击，甚至可能完全不知道请求发生。

所以 prefetch 不能认证某个人，不能证明同意，不能建立账户授权，也不能说明未来一定会导航。格式有效只证明字段可解析，不证明内心意图或业务命令。

这个边界同时约束服务端与客户端。服务端可以按资源成本区别处理推测性流量，但不能仅凭用途标签就断言恶意。客户端可以根据拒绝减少重复预取，却不能断言正常访问被禁止。身份、权限、执行与结果需要各自回执。

把用途当身份会造成危险的二阶效应。一个共享代理发出的请求可能被误归为同一主体；一个真人的不同设备可能被拆成多个类别；安全系统可能把浏览器优化误写成行为画像。窄字段不应承担它没有获得的统治范围。

生成者可能是代表源站的网关

草案允许源站生成 419，也允许代表源站行动的网关生成，例如 CDN 或反向代理。不代表源站的代理不应生成。这使“谁做了决定”成为核心证据。

边缘返回 419，可以支持“该受托边缘拒绝了该请求”。它不能自动支持“源站应用执行了规则”“源站过载”或“所有路径都会拒绝”。同样，受托网关的决定也不是无意义的代理噪声；它可能正是源站授权的控制面。

调查应结合 TLS 终止点、路由、Via、Proxy-Status、请求关联号与双方日志，定位能够被回执证明的最具体节点。RFC 9209 的代理诊断能说明中间处理，但不能替源站签署健康结论。源站没有对应日志，也只说明请求可能没有到达，不会自动指出上游是谁。

权力边界要求两种克制：不能把边缘结论冒充源站事实，也不能因为它发生在边缘就否认委托权。

一次拒绝不是永久策略

草案明确说，这项说明仅适用于关联请求。未来携带相同用途的请求可能成功或失败。任何把单次结果写成资源永久属性的系统，都超出了文本。

两次请求之间，缓存可能变热，负载可能下降，实验开关可能改变，表示成本可能不同，边缘规则可能更新。下一次也可能因为认证、权限或其他故障失败，与用途没有关系。

安全的数据模型记录一个带时间与来源的事件，而不是维护一个无期限的 拒绝预取=true。如果确实存在长期策略，应由经过认证、版本化的配置来证明，而不是让历史结果代理未来权力。

自动化仍可以行动，但动作应可逆：在本地冷却期内停止立即重试，加入抖动，发起有限的普通请求验证，或者等待新的响应。它不应永久封锁资源或客户端。

缓存不能让一次决定治理后续请求

草案指出该状态不具备启发式可缓存性，并且不应被缓存。因为一旦复用，针对一条请求的决定就会被应用到服务端从未评估过的另一条请求。

RFC 9111 定义缓存与新鲜度的一般规则。RFC 9211 的 Cache-Status 可以说明响应是否由缓存提供、转发或重验证。但缓存诊断不会证明策略引擎为何拒绝；419 也不会证明响应是否被复用。

当大量相同响应出现时，应先回答它们是大量新决定，还是一个旧决定被大量播放。年龄、缓存指令、对象键、转发回执和决策节点日志决定计数的含义。否则一个执行动作可以被报成一百次政策选择。

响应正文不应成为隐藏合同

草案说，这类响应不用于向用户展示，正文应为零长度；即使发送了正文，也应丢弃。这个设计阻止自动化从任意错误页中抓取句子，偷偷建立另一套机器协议。

通用模板可能写“容量不足”“稍后再试”或“没有权限”，但这些字句可能与实际拒绝理由无关，也可能由错误配置或中间节点加入。提议中的状态只表达一个窄结论，额外解释需要独立、稳定且有来源的格式。

安全章节还提醒，代码可能泄露内部状态。如果发送与缓存热度、容量阈值或实验开关相关，外部观察者可能反推变化。让授权运维获得更精确分类时，也要评估给探测者增加了多少信息。

来源与限制

冻结资料包括 01 版草案的 HTML 与文本、Datatracker 状态/历史/引用、HTTP 工作组页面、Fetch 标准、RFC 9110 与 9111、代理与缓存状态 RFC、BCP 14 以及 IANA 状态码注册表。这些来源证明提案文本与冻结时的注册状态。

它们不证明任何厂商部署、真实事故、采用比例或最终标准化。开头的告警场景是用于检验推理链的构造案例，不指向任何已知产品或运营商。

来源