摘要

  • HTTP 431 把请求字段过大与请求正文过大区分开来；HTTP 本身并没有为所有实现、所有路径规定同一个字段上限。
  • 拒绝既可能针对字段总量，也可能针对单个字段；缩减后可以重试，但盲目删除上下文会改变认证、条件、路由或操作含义。

正文之前的拒绝

一个没有正文的轻量操作到达网关，却立即被拒。请求里带着长 cookie、访问凭据、表示偏好、追踪信息和转发上下文。每一项单看都可能合理，合计却跨过了某个接收方自行设定的预算。

RFC 6585 在 2012 年把这种情况命名为 431 Request Header Fields Too Large。服务器因为请求字段过大而不愿处理；客户端缩小字段后，可以重新提交。

这里的关键是“字段”。RFC 9110 用 413 表示请求内容超过服务器愿意或能够处理的大小。431 针对的是承载解释、权限、条件与路径的控制信封。因此，请求可以在正文开始之前就已经太大。

标准化的是回答，不是上限

RFC 9110 没有预先规定单行、单值或整个字段区的长度。实现仍然只有有限的内存和解析时间，于是各自决定接收多少。

一条路径便可能拥有多套预算：客户端库能构造，本地代理能转发，边缘网关却拒绝；另一条路径又可能到达限制不同的源站。同样的字节在一处成功、在另一处失败，并不违反某个 HTTP 通用数字，因为这个数字并不存在。

431 只是让私有预算获得共同语言。仅凭状态码，不能证明究竟是哪一跳选择了最小预算，也不能证明把它调高一定安全。

一个字段与字段总和

RFC 6585 允许两种诊断：整个请求字段集合太大，或者某一个字段有问题。若是后者，响应表示应当指出具体字段。

两种情况需要不同修复。孤立的大字段可能可以缩短、刷新或在语义允许时省略；总量超限则可能由数十个分别合理的添加项共同造成。删除最大的一个，并不保证剩余部分能通过下一跳。字段名是线索，不是端到端兼容证明。

责任也未必属于字段表面上的发送者。cookie 会累积历次响应写入的状态，转发字段会被中间节点扩展，令牌轮换会改变凭据长度，追踪系统还会在应用不知情时附加上下文。

静默截断会产生另一条请求

RFC 9110 要求服务器在字段超过其处理意愿时返回合适的 4xx；忽略这些字段会增加请求走私等解释分歧风险。

字段并非装饰。它们可以携带写入前提、身份凭据、目标选择和消息解释规则。一跳忽略、另一跳执行，两者面对的就不再是同一条请求。看似方便的截断，可能把条件写入变成无条件写入，拿走认证依据，或者制造不同的消息边界理解。

服务器还必须收完整个请求头字段区后才能应用请求，因为靠后的字段可能包含条件、凭据或故意误导的重复项。安全分支是明确拒绝，再由理解业务语义的一方重建，而不是由接收方擅自删减。

可以重交，不等于保证成功

RFC 6585 允许在缩减字段后重新提交，但没有承诺成功。下游可能有更低限制；被删字段可能不可缺少；操作可能已经失去时效；若之前遇到传输不确定性，客户端还可能不知道旧尝试是否产生过效果。

可靠的重试应从权威状态重建，保留必需凭据与条件，在应用支持时使用幂等机制，并确认操作仍然值得执行。更快重复一条受损请求，不会恢复它的权限含义。

缓存不能延长本地裁决

RFC 6585 禁止缓存 431 响应。拒绝属于特定字段区、路径和当前接收预算。日后重放，可能误拒已经缩小的请求，也可能把某一跳过去的配置投射成其他路径的规则。

接收方可以根据当前证据产生新的 431；缓存不能把旧解析决定当作可复用内容。

受攻击时，解释本身也有成本

服务器不必总是生成 431。RFC 6585 指出，遭受攻击时，直接丢弃连接或采取其他措施可能更合适。为了构造详细响应而读取、解析数据，会消耗本来要保护的内存与计算；暴露精确阈值还可能帮助探测者校准输入。

资源允许时，有限而准确的说明能帮助正常客户端修复。恶意压力下，更早停止可以优先。但连接关闭本身并不能证明字段过大，内部可观测性必须保留原因差异。

431 的有限真相

431 不表示正文过大，不证明越过了互联网统一上限，也不证明客户端恶意。它只说明：某个接收方拒绝了超过其处理意愿的控制信封。

这条窄小真相把隐藏限制变成可修复分支，同时让预算继续属于本地。持久原则不是一味缩小字段，而是让每一份上下文有边界、有负责人、可重建；绝不能为了塞进信封而删掉使操作安全的权限条件。

来源