本备忘录的状态

这是一份互联网标准轨文档。¶

本文档是互联网工程任务组 （IETF）的成果。它代表了 IETF 社区的共识。它已经 过公开评审，并已获互联网工程指导组 （IESG）批准发布。有关 互联网标准的更多信息，请参阅 RFC 7841 第 2 节。¶

有关本文档的当前状态、任何 勘误以及如何提供反馈的信息，可从 https://www.rfc-editor.org/info/rfc10036 获取。¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

目录

1. 引言

HTTP [HTTP] 允许接收方在 HTTP 消息的各部分到达时便开始处理， 而不要求它们在采取操作之前等待接收完整的 HTTP 消息。¶

某些应用程序经过专门设计，以利用此 能力。¶

例如，服务器发送事件 [SSE] 使用一个长时间运行的 HTTP 响应，其中 服务器会在通知可用时持续发送通知。¶

对于分块的不经意 HTTP 消息 [CHUNKED-OHTTP]，客户端 打开一个 HTTP 请求 并以增量方式发送应用程序数据，而服务器甚至可以在 HTTP 请求 尚未完全结束之前就开始响应。通过这种方式，HTTP 请求-响应对实际上可以创建一个双向 通信通道。¶

当涉及 HTTP 中间方时，依赖数据增量交付的应用程序会比较脆弱。 这是因为 HTTP 中间方不仅被允许，而且经常被 部署为在向下游转发之前缓冲完整的 HTTP 消息 （第 7.6 节，见 [HTTP]）。¶

如果客户端与服务器之间存在这样的缓冲型 HTTP 中间方， 这些应用程序可能无法按预期运行。¶

对于服务器发送事件，试图在转发之前完整缓冲 HTTP 响应的中间方可能会无限期等待。 客户端可能永远无法收到响应的任何部分。¶

对于涉及任何双向交换的请求， 试图缓冲完整消息的中间方—— 无论是请求还是响应——都会阻止任何数据被交付。¶

为帮助避免这种行为，本文档规定了 "Incremental" HTTP 标头 字段，该字段请求 HTTP 中间方在接收到完整消息之前 开始向下游转发 HTTP 消息。¶

中间方可能不支持此指示。 不知道此字段的中间方不会改变其行为。 支持该字段的中间方可能会改为选择拒绝请求； 参见第 4 节。¶

2. 约定和定义

本文档中的关键词“必须”、“不得”、 “要求”、“应当”、“不得 ”、“应该”、“不应该”、“建议”、“不建议”、 “可以”和“可选”仅当它们 如此处所示以全大写形式出现时，才应按照 BCP 14 [RFC2119] [RFC8174] 中的说明进行 解释。¶

本文档依赖于 Item 和 Boolean 的结构化字段定义 [STRUCTURED-FIELDS]。¶

3. Incremental 标头字段

Incremental HTTP 标头字段表达了发送方希望 HTTP 中间方在收到完整 消息之前就开始向下游转发消息的意图。¶

Incremental 标头字段被定义为 Item 类型的结构化字段 [STRUCTURED-FIELDS]。 只有 Boolean 值（第 3.3.6 节，见 [STRUCTURED-FIELDS]）才有效； 如果该字段包含任何其他类型，接收方将忽略该字段。¶

Incremental: ?1

真值（"?1"）表示发送方请求中间方按照下述方式以增量方式转发 消息。¶

Incremental: ?0

假值（"?0"）表示 [HTTP] 中定义的默认行为，其中 中间方可能会在转发之前缓冲整个消息。不过， 这一显式信号可能使中间方在 选择缓冲时更有把握。¶

Incremental HTTP 标头字段适用于每个 HTTP 消息。因此，如果 HTTP 请求和响应都需要以增量方式转发，则 HTTP 请求和响应都必须设置 Incremental HTTP 标头字段。¶

收到包含真值 Incremental 标头字段的标头节后， HTTP 中间方在转发之前不应该缓冲整个消息。 相反，中间方应该向下游传输标头节， 并在消息内容的字节到达时持续转发。由于 Incremental 标头字段仅指示消息内容 应如何转发，因此中间方仍可以在向下游转发之前缓冲消息的整个标头节和尾部 节。¶

如果中间方明确决定拒绝以增量方式转发消息体， 则中间方必须生成错误响应，而不是 缓冲整个消息后再转发。中间方可能拒绝的典型 情形在第 4 节中讨论。¶

使用增量转发的请求也适用于 HTTP 实现。 尽管大多数 HTTP API 都提供以增量方式传输消息内容的能力， 但那些因任何原因不提供这种能力的实现应该利用 Incremental 标头字段的存在来减少或禁用缓冲。¶

中间方可能不支持 Incremental 字段。 不知道该字段 或不支持该字段的中间方可能会缓冲消息， 即使明确请求不要这样做。 因此，客户端和服务器不能期望所有中间方都理解 并遵守以增量方式交付消息的请求。 依赖增量转发支持的客户端可以依靠先验知识， 或探测各个资源是否支持该功能。¶

Incremental 标头字段有助于通过 HTTP 建立双向 字节通道，因为它同时出现在请求和响应中时，会请求 中间方转发提前响应（第 7.5 节，见 [HTTP]），并 在两个方向上以增量方式传输消息内容。不过，在 HTTP 上开发 双向协议时，扩展 CONNECT [RFC8441][RFC9220] 通常 更符合 HTTP 的体系结构。¶

本文档未为 Incremental 标头字段 值定义任何参数，但未来的文档可能会定义参数。接收方必须忽略 未知参数。¶

4. 安全注意事项

当收到请求增量转发的请求或响应时， 中间方可能会出于安全考虑拒绝该 HTTP 请求。 以下小节探讨了中间方可能 拒绝请求的典型情形。¶

请注意，只有当中间方理解 Incremental 字段时， 才会根据该字段的值拒绝请求。¶

5. IANA 注意事项

名为 Incremental 的 HTTP 字段已注册到 “超文本传输协议（HTTP）字段名称注册表”中， 注册过程遵循 第 18.4 节，见 [HTTP]。 注册了以下值：¶

字段名称：

Incremental¶

状态：

永久¶

结构化类型：

Item¶

参考：

本文档¶

注释：

无¶

一个 HTTP 代理错误类型已注册到“HTTP 代理错误类型”注册表中， 如下所示：¶

名称：

incremental_refused¶

描述：

HTTP 消息包含 Incremental HTTP 标头字段，但 中间方拒绝以增量方式转发该消息。¶

额外参数：

无¶

建议的 HTTP 状态码：

501¶

响应仅由中间方生成：

true¶

参考：

本文档¶

6. 参考文献

致谢

作者谨感谢 IETF HTTP 工作组的许多成员 对本规范的讨论和反馈。尤其是，作者 感谢 Mark Thomas、Piotr Sikora、 Thibault Meunier、Marius Kleidl、 Ben Schwartz、 Willy Tarreau、Will Hawkins、Mark Nottingham 和 Lucas Pardue 的细致审阅和修改建议。¶

作者地址