要約

  • Incremental: ?1は、一つのHTTPメッセージについて、全体を受け取る前に下流へ送り始めるよう仲介者へ求める。要求と応答は別のメッセージであり、双方向で必要なら双方に設定する。
  • フィールドを理解する仲介者が本文の逐次転送を全面的に拒む場合、全体を黙ってバッファせずエラーを返さなければならない。恒久的な検査上の不適合は501とincremental_refused、一時的な同時実行数の逼迫は429とconnection_limit_reachedで区別される。
  • 経路全体の保証ではない。未知・非対応ホップはバッファでき、対応ホップも時間またはバイト数に上限を置くバッファを使える。必要なのは、方向、各ホップの認識、方針、閾値、拒否文脈、実測遅延を結ぶ記録である。

双方向の処理を考える。クライアントは本文を送り続け、サーバーは完了前から有用な応答を返す。途中のプロキシが要求全体、または応答全体を待つと、片方は相手のデータを受け取れず進めない。最終的に全データが届いても、対話性という要件はすでに失われている。

RFC 10036「Incremental Forwarding of HTTP Messages」は、2026年8月にIETFの提案標準として公開された。著者はKazuho Oku、Tommy Pauly、Martin Thomsonの3人である。2026年8月31日に保存したIETF記録にはOkuのRFCが4件あり、Fastlyの一次プロフィールはPrincipal OSS Engineer、H2O、quicly、picoTLSの作者と紹介する。これは高性能ネットワークソフトウェアへの継続的な関与を示すが、RFCの単独発明や導入経路への支配を意味しない。

意図は接続ではなくメッセージに付く

IncrementalはStructured FieldsのItemで、正しい値はBooleanだけである。別の型なら無視される。?1は逐次転送の要求、?0はメッセージ全体をバッファし得る通常動作を明示する。

単位がメッセージであることは重要だ。要求に付けても応答には継承されない。応答も逐次転送してほしいならサーバーが応答側に付ける。したがって「このAPIはストリーミング対応」という評価は、どちらの方向を試したかがなければ不完全である。

対応仲介者はヘッダー部を送り、その後は到着する本文のバイトを継続的に転送すべきである。ただし、ヘッダーとトレーラー全体のバッファは許される。フィールドは新しいトランスポートではない。双方向プロトコルにはExtended CONNECTのほうがHTTPの構造に一般に整合するとRFC自身が指摘する。

拒否を成功に見せない

仲介者がフィールドを理解しながら本文の逐次転送を明確に拒むなら、エラーを生成する必要がある。全体をためてから送り、最終結果だけを成功に見せてはいけない。

明示的なエラーなら、別経路、別プロトコル、再試行、機能縮小を選べる。黙ったバッファは、接続を正常に見せながら最初のバイトを遅らせる。監視画面、イベント通知、早期応答では、遅れて届く成功が業務上の失敗になり得る。

ただし、あらゆる遅延が拒否という意味ではない。即時に1バイトずつ送る義務でもない。観測可能になるのは、参加ホップが行った特定の方針判断である。実運用経路で識別可能なチャンクを流し、受信・転送時刻を測り、拒否条件を再現してProxy-Statusまで届くか確認することが、Running-Code Primacyに沿った証明となる。

501と429は異なる経営課題を示す

本文全体を見て安全性を判定する仲介機能は、逐次転送と両立しない。その理由で拒否する場合、RFCは501 Not ImplementedとProxy-Statusのincremental_refusedを推奨する。再試行だけでは変わりにくく、検査方式、経路、資源配置、プロトコルの判断が必要になる。

もう一つは容量である。長く生きる逐次要求は資源を占有するため、仲介者は通常要求を守る目的で専用の同時実行上限を設けられる。上限到達時は429 Too Many Requestsとconnection_limit_reachedが推奨される。こちらは一時的であり、バックオフ、優先度、入場制御、増強が対応候補となる。

状態コードだけでは原因を確定できない。501も429も別用途がある。Proxy-Status、責任ホップ、資源、方針版、時刻を結んで初めて判断できる。参加しないホップの情報がないことも、証拠の欠落として残す必要がある。

未対応ホップは沈黙できる

フィールドを知らない仲介者は動作を変えない。認識しても対応しない実装もバッファできる。したがって、エラーがないことは経路全体の対応を証明しない。

対応して拒否するホップは原因を示すぶん透明である。未知のホップは遅延だけを加えて通過できる。この盲点を減らす方法が、検証済みの事前知識と個別資源へのプローブである。

同じホストでも地域、経路、本文型、顧客区分、負荷により方針が変わる。成功したプローブは、その時点・条件の証拠であって、企業名への永久認証ではない。送信者は意図を表明し、各仲介者は自分の安全と容量を決め、端点は結果を解釈する。この権限分界を越えて約束してはならない。

小さなバッファにもSLOがある

多数の小片を即時転送するコストや悪用を抑えるため、対応ホップも少量のバッファを使える。バイト上限または時間上限に達したら転送し、無期限には保持できない。

この裁量により、「対応」と「必要な初回バイト時間」は別になる。大量応答では問題ないバイト閾値が、低頻度イベントでは長い待ちになる。人向け画面に短いタイマーも、機械制御には長すぎるかもしれない。

閾値と同時実行クラスを版管理し、初回バイト測定と結ぶべきである。共通規格は最小の信号と拒否を定め、個別導入は対象資源、検査、容量、閾値、代替策を明示する。Minimum Initial Specificationは、その役割分担を崩さないための原則である。

経路から結果までを一つの記録にする

クライアント、サーバー、資源、ビルド、メッセージID、要求/応答の方向を記録する。フィールドの原値、Booleanとしての妥当性、設定した主体と目的も必要だ。

制御下または参加する各仲介者について、プロトコル区間、認識・対応状況、検査規則、本文/ヘッダー/トレーラー方針、時間・バイト閾値、同時実行プール、占有率、優先度を残す。結果側ではHTTP状態、Proxy-Status、エラー型、責任ホップ、最初と最後のバイトの受信・転送時刻、アプリのSLOを結ぶ。

その上で、正常な逐次転送、上限付きバッファによる劣化、恒久拒否、一時拒否、未知箇所での黙ったバッファ、判定不能を分ける。再試行、経路変更、プロトコル変更、増強、セキュリティ例外、機能縮小の責任者と期限も保存する。

本文そのものを保管する必要はない。安全な相関ID、時刻、方針版で十分な場合が多い。見えないホップや失われたProxy-Statusを「対応済み」に変換せず、空白として残すことが信頼性を高める。

情報源