要約

  • RFC 10036 は Boolean の HTTP フィールド Incremental を定義した。真は、メッセージ全体を受信する前に内容を逐次転送するよう中間ノードへ求める。理解していながら拒否するノードは、黙って全体をためずエラーを返さなければならない。
  • このフィールドは能力交渉でも配達証明でもない。未対応ノードは無視でき、要求と応答は別々に指定する必要があり、時間またはバイト数で上限を付けた小さなバッファも許される。最初のイベントの移動は観測で確かめる必要がある。

正しい指示も次のホップで消える

冒頭の終わらないイベントストリームは、ローカルな処理規則とエンドツーエンドの結果を分ける。最初のプロキシは送信者の意図を読み取り、逐次モードを選べる。二つ目はフィールドを実装しておらず、通常の HTTP 処理を続ける。通常の中間ノードにはメッセージ全体をバッファする余地があるため、知らない規則に違反せず永久に待ち続けられる。

RFC 10036 は、経路上の全ノードが理解したことを返す肯定応答を定義していない。オリジンからフィールドが出た事実は意図だけを証明する。あるプロキシから早期バイトが出た事実は、そのホップだけの証拠である。HTTP 200 も、最初の内容が利用者まで届いたことを保証しない。

これは HTTP Priority の問題とは違う。Priority は競合する有資格バイトのうち何を先に送るかをスケジューラーへ伝える。Incremental は、最後のバイトが到着する前に当該ホップが内容を動かし始めるかを問う。逐次転送しながら帯域配分が小さい経路も、高優先度なのに後段で完了待ちになる経路もあり得る。

RFC 10036 が作ったのは狭い処理契約だ

RFC Editor は 2026 年 8 月、HTTP Working Group の成果を IETF Standards Track の RFC 10036 として公開した。IANA は Incremental を Structured Field の Item 型を持つ恒久 HTTP フィールドとして登録し、incremental_refused も HTTP Proxy Error Type に追加した。

有効値は Structured Fields の Boolean である。?1 は逐次転送を要求し、?0 は既定動作を明示する。後者は、全体をバッファしてよいという判断を中間ノードに与えやすくする。別の型なら無視され、未知のパラメーターも無視される。この構文は暗黙の能力交渉にはならない。

適用範囲は一つの HTTP メッセージである。アップロード中に応答も動かす双方向交換なら、要求と応答の双方に真を設定する必要がある。要求側の指定が応答側を代理することも、その逆もない。

フィールドを理解して受け入れた中間ノードは、ヘッダーセクションを下流へ送り、内容が到着するたびに転送を続けるべきである。ただしヘッダーやトレーラーのセクション全体を集めることはできる。規定対象は内容転送の様式であり、全処理の即時性ではない。

明示的な拒否は設計上の証拠になる

安全性を判定するためメッセージ全体を必要とする検査機能は、早期転送と両立しない。RFC 10036 は送信者に検査を解除する権限を与えない。理解している中間ノードには、逐次転送するか、受理して黙って待つのではなく拒否するかを求める。

内容検査上の恒久的な非互換なら、501 と Proxy-Status の incremental_refused が推奨される。見えない停滞が分類可能な拒否になり、オリジン遅延や通信障害と区別しやすくなる。

一時的な容量不足は別である。長寿命の逐次要求は接続と同時実行状態を占有するため、他の処理を守る目的で厳しい上限を設けられる。上限到達時は 429 と connection_limit_reached が推奨される。

しかしステータスだけで経路全体を説明してはならない。Proxy-Status はノードが任意に生成し、内部構成を守るため詳細を省ける。後続ノードが削除することも、トレーラーが失われることもある。報告元、適用されたポリシーと容量状態、ローカル計測を結び付ける必要がある。

逐次はゼロバッファを意味しない

小さな書き込みを一つずつ即時送信すると、CPU、帯域、下流処理を浪費する可能性がある。このため規格は逐次メッセージにも少量のバッファを認める。実装はバイト数または待ち時間のしきい値で解放できる。

有界なまとめ処理と全体バッファの差は、進捗期限がメッセージ完了から独立しているかにある。16 KB や 20 ミリ秒は検証できる遅延枠だが、「本文が終わるまで」は終わらないストリームに期限を与えない。

送信者は ?1 から具体的なしきい値を知れない。フィールドはフロー制御や輻輳制御を迂回せず、帯域を予約せず、ネットワークパケットの即時送信も約束しない。HTTP ライブラリ、プロキシ、TLS、カーネル、トランスポートはそれぞれ遅延を追加し得る。

したがってサービス目標は「バッファ無効」ではなく、所定のメッセージ量、イベント間隔、同時負荷、障害条件における、各ホップの受信から最初および継続出力までの時間とバイト分布で表すべきだ。

未対応ノードが最も硬い境界になる

理解したノードが拒むならエラーが必要だが、理解していないノードはその義務にも従えず、従来どおり無視してバッファできる。この非対称性のため、規格は事前知識またはリソース単位のプローブを挙げる。

一度の成功は、その時点の URL、POP、ソフトウェア、HTTP 版、経路だけの証拠だ。CDN は検査層を増やし、テナントを別ゲートウェイへ移し、上流プロトコルを変え、複数世代へ流量を分ける。短く終了する応答だけの試験では、無限ストリームの永久待ちを見落とす。

能力記録には経路と時刻が要る。DNS とルーティング選択、プロキシ識別子、HTTP 版、設定改訂、フィールド保持、バッファしきい値、最初のヘッダーと内容の時刻、継続間隔、クライアント観測を保存し、構成変更後に再試験する。

長時間応答と双方向利用は別のリスクを示す

Server-Sent Events は、全体バッファが無期限待ちになる最も明快な応答側事例である。ヘッダー到達だけでなく、全本番経路でイベントが所定間隔に現れることを試験しなければならない。

Chunked Oblivious HTTP は、要求を送り続けながら応答が始まる双方向例を提供する。両メッセージに別々の指定が要る。IESG writeup は、このフィールドの実装がまだ少ないとも述べており、推測ではなく実測が必要だ。

RFC 10036 は、双方向プロトコルには一般に Extended CONNECT の方が HTTP の構造に合うとも指摘する。HTTP/2 と HTTP/3 には WebSocket 用の仕組みがある。新フィールド一つで全プロキシ経路が汎用トンネルになると考えてはならない。

意図から観測された進捗までをつなぐ

送信者はメッセージ上の意図を、中間ノードは実装、検査、容量、バッファ上限を、アプリケーション責任者は経路が製品要件に足りるかと安全な代替策を所有する。

証拠はメッセージ識別子、方向、Boolean の解析から始まり、各ホップのソフトウェアと設定、フィールド伝播、処理モード、時間・バイトしきい値、入出力時刻、拒否と信頼できる Proxy-Status を経て、クライアントの最初のイベント、継続間隔、アプリケーション状態、資源影響に到達する。

登録済みフィールドは対応を証明せず、対応は今回の使用を証明せず、一ホップの出力は配達を証明せず、最初のバイトは継続可能性を証明しない。規格は隠れた選択を表現可能にした。実際にバイトがどこへ進んだかは運用証拠が示す。

出典