摘要

  • RFC 10036 定义了布尔型 HTTP 字段 Incremental。真值要求中间节点在收到完整消息前持续转发内容；认识该字段但明确拒绝的节点，必须返回错误，而不能悄悄改为整条消息缓冲。
  • 这个字段不是能力协商，也不是送达回执。不认识它的节点仍可忽略它；请求和响应需要分别声明；为控制小包成本而设置的字节或时间上限缓冲仍然允许。首事件是否移动，必须逐跳观察。

正确指令可能在下一跳失效

开篇中的无限事件流把“本地处理规则”和“端到端结果”分开。第一层代理知道发送方希望增量转发，因此可以选择相应模式。第二层代理没有实现这个字段，只执行 HTTP 的一般行为。一般中间节点本来就可以等到消息完整后再转发，所以它可能一直等待，却没有违反一条自己根本不认识的规则。

RFC 10036 没有定义“所有中间节点均已理解”的正向确认。看到字段离开源站，只证明发送方表达过意图；看到字节离开某一层代理，只证明那一跳发生过进展。即使最终状态码是 200，也不能倒推出第一个内容字节已抵达用户。

这与 HTTP Priority 的权力问题不同。优先级帮助调度器在竞争条件下决定哪些合格字节先走；Incremental 解决的是消息最后一个字节到达之前，当前这一跳是否开始移动内容。路径可以增量转发却只分到很少资源，也可以给予高优先级却在后续节点等待消息结束。

RFC 10036 建立的是窄处理契约

RFC Editor 在 2026 年 8 月将 RFC 10036 作为 IETF 标准轨文件发布，工作来自 HTTP 工作组。IANA 已把 Incremental 登记为永久 HTTP 字段，结构类型为 Item，并把 incremental_refused 登记为 HTTP 代理错误类型。

有效值是 Structured Fields 的布尔值。?1 请求增量转发；?0 表示采用默认行为，甚至可能增强中间节点整条缓冲的信心。其他类型的值会被忽略。未来可以增加参数，但未知参数也被忽略，而不会把这个字段变成隐含的协商协议。

作用域是单条 HTTP 消息。如果应用希望上传尚未结束时响应已经开始，那么请求和响应都要分别带真值。请求字段不能替响应作决定，响应字段也不能追溯改变请求体的处理方式。

理解并接受真值的中间节点应发送完整标头段，然后随着内容字节到达而持续向下游转发，不应等完整内容。它仍然可以收齐标头段或尾部段。字段控制的是内容转发方式，不是每一种处理边界。

明确拒绝本身就是证据

某些安全功能必须看到完整消息，才能判断内容能否放行。这与提前转发天然冲突。RFC 10036 没有授予发送方关闭检查的权力；它要求理解字段的中间节点诚实选择：要么增量转发，要么返回错误，不能先接受再无限等待。

如果内容安全策略永久不允许这种模式，规范建议返回 501，并在 Proxy-Status 中给出 incremental_refused。这把不可见的停顿转成可归类的拒绝，让运营者把“这里不能增量工作”与源站迟缓、传输丢失区分开。

容量约束是另一类拒绝。长时间存在的增量请求会占用连接与并发状态，中间节点可以给它们设更严格的上限，以保护其他流量。到达上限时，规范建议返回 429，并用 Proxy-Status 的 connection_limit_reached 解释原因。

状态码仍不是完整路径证明。Proxy-Status 由中间节点自行生成，可能为了不泄露内部结构而省略细节，也可能在后续路径被删除。作为尾部字段发送时还可能丢失。可信记录必须包含报告节点身份、当时的策略与容量状态，以及本地遥测的相互印证。

增量转发不等于零缓冲

把每个微小写入立即变成独立发送会浪费 CPU、带宽和下游处理成本，因此规范允许少量缓冲。实现可以在累计到字节门槛或等待到时间门槛时释放数据。

有界合并与整条消息缓冲的关键差异，是进展上限是否独立于消息完成。16 KB 或 20 毫秒是可以验证的延迟包络；“等消息结束”则不是，尤其当流会持续数小时。

发送方不能从 ?1 推断具体门槛。字段也不会绕过流量控制或拥塞控制，不会预留带宽，更不会承诺立即发出网络包。HTTP 库、代理、TLS、内核和传输路径都可能在应用选择模式后继续引入延迟。

所以有效的服务目标不是一句“关闭缓冲”，而是在明确消息大小、事件节奏、并发负载和故障状态下，测量每一跳入站到首个出站字节以及后续持续出站的时间和字节分布。

不认识字段的节点才是硬边界

理解字段的节点若决定不接受，必须拒绝；不理解字段的节点却无法遵守这条要求，仍可能像过去一样忽略并缓冲。这种不对称正是规范建议应用依赖既有知识或按资源探测的原因。

一次探测只能证明当时那条路径、那个 URL、那个 POP、那个软件版本和协议组合。CDN 可能增加安全层，把租户迁到另一网关，改变上游 HTTP 版本，或让不同流量进入不同代际的软件。只测源站到边缘，可能看不到边缘到用户之间的缓冲；只测会快速结束的小响应，也可能漏掉无限流的永久等待。

能力证据必须带路径和时间：记录 DNS 与路由选择、中间节点身份、HTTP 版本、配置修订、字段保留、缓冲门槛、首标头与首内容时间、持续节奏和客户端观察，并在拓扑或策略改变后重新验证。

长连接与双向用例暴露不同风险

Server-Sent Events 是最直接的响应侧例子，因为整条缓冲会变成无限等待。应用必须证明每个生产路径上的事件以预期节奏出现，而不只是响应标头已经到达。

Chunked Oblivious HTTP 展示了双向情形：客户端继续发送应用数据时，服务器可以开始回答。请求和响应必须各自声明。IESG 报告还指出，这个字段的实际实现目前很少，因此部署不能靠想当然。

RFC 10036 同时提醒，双向协议一般更适合使用 Extended CONNECT。HTTP/2 和 HTTP/3 都为 WebSocket 定义了相应机制。选择普通请求—响应加增量内容，应当是经过验证的兼容性决定，而不是认为一个新字段能把所有代理路径自动变成通用隧道。

从意图一直保留到实际进展

发送方负责它写入消息的意图。每个中间节点负责自身的实现、检查策略、容量限制和缓冲上限。应用负责人负责判断观察到的路径是否满足产品需要，以及失败时采用何种安全退路。

证据链从消息身份、方向和精确布尔解析开始，经过每一跳的软件与配置、字段传播、本地处理模式、字节与时间门槛、入站和出站时间、拒绝状态与可信 Proxy-Status，最后落到客户端首事件、持续节奏、应用状态和资源影响。

不要把第一层提升成最后一层。字段登记不证明支持，支持不证明本次请求使用了它，一跳出站不证明端到端抵达，首字节抵达也不证明服务可以安全持续。新标准让隐藏的选择可以被表达；运行证据仍要回答字节到底去了哪里。

来源