| RFC 10036 | HTTP メッセージの逐次転送 | 2026年8月 |
| Oku ほか | 標準化過程 | [ページ] |
この文書は "Incremental" HTTP ヘッダーフィールドを規定するものであり、これは HTTP 中継者に HTTP メッセージを逐次転送するよう指示する。¶
これはインターネット標準化過程の文書である。¶
この文書はインターネット技術タスクフォース (IETF) の成果物である。これは IETF コミュニティの総意を表す。公開 レビューを受け、インターネット技術運営グループ (IESG) によって公開が承認されている。インターネット標準に関する詳細な 情報は RFC 7841 の第2節で入手できる。¶
この文書の現在の状況、正誤情報、および この文書に関するフィードバックの提供方法については、 https://www.rfc-editor.org/info/rfc10036 で確認できる。¶
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.¶
HTTP [HTTP] は、受信者が HTTP メッセージ全体を受信してから処理を開始することを要求するのではなく、 HTTP メッセージの各部分が到着するにつれて処理を開始することを許可している。¶
一部のアプリケーションは、この 機能を利用するように特別に設計されている。¶
たとえば、Server-Sent Events [SSE] は長時間継続する HTTP レスポンスを使用し、 サーバーは通知が利用可能になるたびに継続的に送信する。¶
Chunked Oblivious HTTP Messages [CHUNKED-OHTTP] の場合、クライアントは HTTP リクエストを開始してアプリケーションデータを逐次送信し、 サーバーは HTTP リクエストが完全に完了する前でも応答を開始できる。このようにして、HTTP リクエストとレスポンスの組は、実質的に双方向の 通信チャネルを形成できる。¶
データの逐次配信に依存するアプリケーションは、HTTP 中継者が関与すると脆弱になる。 これは、HTTP 中継者には HTTP メッセージ全体を下流へ転送する前に バッファリングすることが許可されているだけでなく、実際にそのように 配備されることが多いためである ([HTTP] の 第 7.6 節)。¶
このようなバッファリングを行う HTTP 中継者がクライアントとサーバーの間に存在すると、 これらのアプリケーションは意図したとおりに機能しない可能性がある。¶
Server-Sent Events の場合、HTTP レスポンス全体を転送前にバッファリングしようとする中継者は、無期限に待機し続ける可能性がある。 クライアントはレスポンスのどの部分も受信できない可能性がある。¶
何らかの双方向交換を伴うリクエストの場合、 リクエストかレスポンスかを問わず、メッセージ全体をバッファリングしようとする 中継者は、あらゆるデータの配信を妨げる。¶
このような動作を回避しやすくするため、この文書では "Incremental" HTTP ヘッダー フィールドを規定する。これは HTTP 中継者に対し、完全なメッセージを受信する前に HTTP メッセージを下流へ転送し始めるよう要求する。¶
この指定は中継者によってサポートされない可能性がある。 このフィールドを認識しない中継者は、その動作を変更しない。 このフィールドをサポートする中継者は、代わりにリクエストを拒否することを選択する可能性がある。 第 4 節を参照。¶
この文書におけるキーワード「しなければならない」、「してはならない」、 「必須」、「しなければならない」、「しては ならない」、「するべきである」、「するべきではない」、「推奨される」、「推奨されない」、 「してもよい」、および「任意」は、ここに示すように すべて大文字で現れる場合、かつその場合に限り、 BCP 14 [RFC2119] [RFC8174] に記載されているとおりに 解釈されるものとする。¶
この文書は、Item および Boolean の Structured Fields 定義 [STRUCTURED-FIELDS] に依存する。¶
Incremental HTTP ヘッダーフィールドは、HTTP 中継者に対し、メッセージ全体を受信する前にメッセージを下流へ 転送し始めてほしいという送信者の意図を表す。¶
Incremental ヘッダーフィールドは、Item 型の Structured Field [STRUCTURED-FIELDS] として定義される。 Boolean 値 ([STRUCTURED-FIELDS] の 第 3.3.6 節) のみが有効である。 他の型が含まれている場合、受信者はそのフィールドを無視する。¶
true 値 ("?1") は、以下に記載するように、送信者が中継者に メッセージを逐次転送するよう要求していることを示す。¶
false 値 ("?0") は [HTTP] で定義される既定の動作を示し、この場合 中継者は転送前にメッセージ全体をバッファリングする可能性がある。ただし、 この明示的なシグナルによって、中継者はバッファリングを選択することに より大きな確信を持てる可能性がある。¶
Incremental HTTP ヘッダーフィールドは各 HTTP メッセージに適用される。したがって、 HTTP リクエストとレスポンスの両方を逐次転送する必要がある場合、 Incremental HTTP ヘッダーフィールドを HTTP リクエストと レスポンスの両方に設定しなければならない。¶
true 値を持つ Incremental ヘッダーフィールドを含むヘッダーセクションを受信した場合、 HTTP 中継者は、転送前にメッセージ全体をバッファリングするべきではない。 代わりに、中継者はヘッダーセクションを下流へ送信し、 メッセージ内容のバイトが到着するにつれて継続的に転送するべきである。 Incremental ヘッダーフィールドはメッセージ内容をどのように 転送するかのみを示すため、中継者はメッセージのヘッダーセクションとトレーラー セクション全体を下流へ転送する前に引き続きバッファリングできる。¶
中継者がメッセージ本文の逐次転送を完全に拒否すると決定した場合、 中継者はメッセージ全体をバッファリングしてから転送するのではなく、 エラーレスポンスを生成しなければならない。 中継者が拒否する可能性のある典型的な状況については、第 4 節で説明する。¶
逐次転送を使用する要求は HTTP 実装にも適用される。 ほとんどの HTTP API はメッセージ内容を逐次転送する機能を提供するが、 何らかの理由でそれを提供しないものは、Incremental ヘッダーフィールドの存在を利用してバッファリングを削減または無効化するべきである。¶
Incremental フィールドは中継者によってサポートされない可能性がある。 このフィールドを認識しない中継者、 またはこのフィールドをサポートしない中継者は、 明示的にそうしないよう要求された場合でもメッセージをバッファリングする可能性がある。 したがって、クライアントとサーバーは、すべての中継者が メッセージを逐次配信する要求を理解し、尊重することを期待できない。 逐次転送のサポートに依存するクライアントは、事前知識に依存するか、 個々のリソースについてサポートを調査できる。¶
Incremental ヘッダーフィールドは HTTP 上での双方向 バイトチャネルの確立を容易にする。リクエストとレスポンスの両方に存在することで、 中継者に早期レスポンス ([HTTP] の 第 7.5 節) を転送し、 メッセージ内容を両方向で逐次送信するよう要求するためである。ただし、HTTP 上で 双方向プロトコルを開発する場合、Extended CONNECT [RFC8441][RFC9220] は 一般に HTTP のアーキテクチャとの整合性がより高い。¶
この文書では Incremental ヘッダーフィールド値のパラメーターを 定義していないが、将来の文書でパラメーターが定義される可能性がある。受信者は 未知のパラメーターを無視しなければならない。¶
逐次転送を要求するリクエストまたはレスポンスを受信した場合、 中継者はセキュリティ上の懸念から HTTP リクエストを拒否する可能性がある。 以下の各小節では、中継者がリクエストを拒否する可能性のある 典型的な状況を検討する。¶
Incremental フィールドの値に基づいてリクエストを拒否するのは、 中継者がこのフィールドを理解している場合に限られることに注意すること。¶
一部の中継者は HTTP メッセージの内容を検査し、 その内容が安全であると判断された場合にのみ転送する。このように メッセージ全体を見ることに依存するあらゆる機能は、逐次配信と互換性がない。¶
中継者がメッセージを逐次転送するよう求められたものの、 そのメッセージがリクエストかレスポンスかにかかわらず、 メッセージ内容に関するセキュリティ上の懸念によりそれができない場合、 中継者は incremental_refused Proxy-Status レスポンスヘッダーフィールド (第 5 節) を伴う 501 (未実装) エラーで 応答するべきである。¶
HTTP リクエストや接続の処理に必要なリソースを節約するため、 中継者が転送する同時 HTTP リクエストの最大数に制限を設け、 この制限を超えたリクエストをバッファリングすることは一般的である。¶
このような中継者は、逐次としてマークされた リクエストに対してより厳しい同時実行数の制限を適用し、 逐次リクエストの最大数に達した場合でも 非逐次リクエストに利用可能な容量を確保できる。この方法は、異なる種類の リクエストの処理のバランスを取り、すべてのリクエストに対するサービスの可用性を維持するのに役立つ。¶
同時実行数の制限に達したために逐次リクエストを拒否する場合、 中継者は 429 (リクエスト過多) エラー ([EXTRA-STATUS] の 第 4 節) とともに、connection_limit_reached Proxy-Status レスポンスヘッダーフィールド ([PROXY-STATUS] の 第 2.3.12 節) を付けて応答するべきである。¶
性能と効率上の理由から、逐次メッセージの場合でも、 中継者によって少量のバッファリングが使用される可能性がある。即時転送は、 中継者に多数の小さなパケットへの処理を浪費させるために悪用される可能性がある。 その代わりに、逐次配信を有効にすると、バッファリングされる バイト数や、転送前にバッファーが保持される時間の長さに制限を設定できる。 バッファリングは、効率を改善する場合でも、アプリケーションのレイテンシーに 悪影響を与える可能性がある。いずれの場合も、中継者はデータをバッファーに 無期限に保持することはできないため、時間制限または バイト制限のいずれかに達した時点でデータを転送する必要がある。¶
Incremental という名前の HTTP フィールドが、 [HTTP] の 第 18.4 節の手順に従って 「Hypertext Transfer Protocol (HTTP) Field Name Registry」に登録された。 次の値が登録されている。¶
HTTP Proxy Error Type が、以下に示すように「HTTP Proxy Error Types」レジストリに 登録された。¶