HTTP/3

HTTP/1.1 ([HTTP/1.1]) は、空白で区切られたテキストフィールドを用いて HTTP メッセージを伝達します。これらの交換は人間が読みやすい一方で、メッセージ形式に空白を用いることはパースの複雑性とバリアント挙動に対する過度の寛容さを招きます。

HTTP/1.1 は多重化レイヤーを含まないため、複数の TCP 接続が並列にリクエストを処理するために用いられることがよくあります。しかし、TCP は複数接続間で輻輳制御を共有しないため、これは輻輳制御とネットワーク効率に悪影響を及ぼします。

HTTP/2 ([HTTP/2]) は、トランスポート層を変更せずにレイテンシを改善するためにバイナリフレーミングと多重化レイヤーを導入しました。しかし、HTTP/2 の多重化の並列性が TCP の損失回復メカニズムに見えないため、パケットの喪失や順序の乱れが発生すると、その損失パケットに直接影響を受けていないトランザクションであってもアクティブなすべてのトランザクションが停滞することになります。

QUIC トランスポートプロトコルは、HTTP/2 フレーミング層が提供するものと類似したストリーム多重化およびストリームごとのフロー制御を組み込みます。ストリームレベルでの信頼性と接続全体での輻輳制御を提供することにより、QUIC は TCP マッピングと比較して HTTP の性能を改善する能力を持ちます。QUIC はまたトランスポート層で TLS 1.3 ([TLS]) を組み込み、TCP 上で TLS を動作させる場合と同等の機密性と完全性を提供しつつ、TCP Fast Open ([TFO]) による接続確立遅延の改善も提供します。

本書は HTTP/3 を定義します：QUIC トランスポートプロトコル上での HTTP セマンティクスのマッピングであり、HTTP/2 の設計を大いに踏襲しています。HTTP/3 はデータの機密性および完全性保護、ピア認証、およびストリームごとに順序通りでの信頼できる配信を提供するために QUIC に依存します。ストリームのライフタイムやフロー制御の問題を QUIC に委譲しつつ、各ストリーム上で HTTP/2 のフレーミングに類似したバイナリフレーミングを使用します。いくつかの HTTP/2 機能は QUIC に包含され、他の機能は QUIC 上に実装されます。

QUIC は [QUIC-TRANSPORT] に記述されています。HTTP/2 の完全な記述については [HTTP/2] を参照してください。

• "Connection Setup and Management" (Section 3) は HTTP/3 エンドポイントの検出方法と HTTP/3 接続の確立方法を扱います。
• "Expressing HTTP Semantics in HTTP/3" (Section 4) はフレームを用いて HTTP セマンティクスがどのように表現されるかを説明します。
• "Connection Closure" (Section 5) は HTTP/3 接続がどのように優雅にまたは突然終了されるかを説明します。

• "Stream Mapping and Usage" (Section 6) は QUIC ストリームの使用方法を説明します。
• "HTTP Framing Layer" (Section 7) はほとんどのストリームで使用されるフレームを説明します。
• "Error Handling" (Section 8) は、特定のストリーム上または接続全体に対してエラー条件がどのように処理され表現されるかを説明します。

• "Extensions to HTTP/3" (Section 9) は将来の文書でどのように新しい機能が追加できるかを説明します。
• HTTP/2 と HTTP/3 のより詳細な比較は Appendix A にあります。

この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、それらがすべて大文字で現れる場合に限り、BCP 14 に記載されているように解釈されます。[RFC2119] [RFC8174]

この文書は可変長整数エンコーディングを [QUIC-TRANSPORT] から使用します。

abort:

接続またはストリームの突然の終了。エラー条件による場合があります。

client:

HTTP/3 接続を開始するエンドポイント。クライアントは HTTP リクエストを送信し、HTTP レスポンスを受信します。

connection:

QUIC をトランスポートプロトコルとして使用する、二つのエンドポイント間のトランスポート層の接続。

connection error

:

HTTP/3 接続全体に影響を与えるエラー。

endpoint:

接続のクライアントまたはサーバのいずれか。

frame:

HTTP/3 におけるストリーム上の通信の最小単位で、ヘッダとフレームタイプに従って構造化された可変長のバイト列から成ります。

この文書と [QUIC-TRANSPORT] の両方に「frame」と呼ばれるプロトコル要素が存在します。[QUIC-TRANSPORT] からのフレームが参照される場合、フレーム名は "QUIC" で前置されます。例えば "QUIC CONNECTION_CLOSE frames" のようになります。この前置がない参照は Section 7.2 で定義されたフレームを指します。

HTTP/3 connection:

合意されたアプリケーションプロトコルが HTTP/3 である QUIC 接続。

peer:

エンドポイント。特定のエンドポイントについて議論する際、"peer" は議論の主体に対してリモートにあるエンドポイントを指します。

receiver:

フレームを受信しているエンドポイント。

sender:

フレームを送信しているエンドポイント。

server:

HTTP/3 接続を受け入れるエンドポイント。サーバは HTTP リクエストを受信し、HTTP レスポンスを送信します。

stream:

QUIC トランスポートが提供する双方向または一方向のバイトストリーム。すべてのストリームは HTTP/3 接続内で「HTTP/3 ストリーム」と見なせますが、HTTP/3 内では複数のストリームタイプが定義されています。

stream error

:

個々のストリーム上のアプリケーションレベルのエラー。

"content" という用語は Section 6.4 の [HTTP] で定義されています。

最後に、"resource", "message", "user agent", "origin server", "gateway", "intermediary", "proxy", および "tunnel" の用語は Section 3 の [HTTP] で定義されています。

本書のパケット図は、フィールドの順序とサイズを示すために Section 1.3 の形式を使用します（参照：[QUIC-TRANSPORT]）。

HTTP は「権威あるレスポンス（authoritative response）」の概念に依存します：これは、ターゲット URI に識別されるオリジンサーバによって（またはその指示で）レスポンスメッセージが生成された時点でのターゲットリソースの状態を考慮して、そのリクエストに対して最も適切であると判断されたレスポンスです。HTTP URI の権威あるサーバの位置特定は Section 4.3 の [HTTP] で議論されています。

"https" スキームは、クライアントがその URI の authority コンポーネントで識別されたホストに対して信頼できるとみなす証明書の所有を権限と関連付けます。TLS ハンドシェイクでサーバ証明書を受け取った際、クライアントは Section 4.3.4 のプロセスを用いてその証明書が URI のオリジンサーバに対して許容できるマッチであることを検証しなければなりません。もし証明書が URI のオリジンサーバに関して検証できない場合、クライアントは当該サーバをそのオリジンに対する権威あるサーバと見なしてはなりません。

クライアントは、ホスト識別子を IP アドレスに解決し、指定されたポートへのそのアドレスに対して QUIC 接続を確立し（上記のサーバ証明書の検証を含む）、その保護された接続上で当該 URI をターゲットとする HTTP/3 リクエストメッセージをサーバに送信することで、"https" URI のリソースへのアクセスを試みることができます（この動作は MAY です）。HTTP/3 を選択するための他のメカニズムが使用されない限り、トークン "h3" は TLS ハンドシェイク中の Application-Layer Protocol Negotiation (ALPN; 参照 [RFC7301]) 拡張で使用されます。

接続性の問題（例：UDP のブロック）は QUIC 接続の確立失敗をもたらす可能性があるため、クライアントはこの場合に TCP ベースの HTTP の使用を試みるべきです（SHOULD）。

サーバは任意の UDP ポートで HTTP/3 を提供してもよく（MAY）、代替サービス広告は常に明示的なポートを含み、URI は明示的ポートかスキームに関連付けられたデフォルトポートのいずれかを含みます。

HTTP/3 は基盤となるトランスポートとして QUIC バージョン 1 に依存します。他の QUIC トランスポートバージョンを HTTP/3 と共に使用することは将来の仕様で定義されうる（MAY）。

QUIC バージョン 1 はハンドシェイクプロトコルとして TLS バージョン 1.3 以上を使用します。HTTP/3 クライアントは TLS ハンドシェイク中にサーバへのターゲットホストを示す仕組みをサポートしなければなりません（MUST）。サーバがドメイン名で識別される場合（[DNS-TERMS]）、クライアントは Server Name Indication (SNI; [RFC6066]) TLS 拡張を送信しなければなりません（MUST）、代替のホスト指示メカニズムが使われない限り。

QUIC 接続の確立は [QUIC-TRANSPORT] に記述されている通りです。接続確立中に、HTTP/3 サポートは TLS ハンドシェイクで ALPN トークン "h3" を選択することで示されます。その他のアプリケーション層プロトコルのサポートが同じハンドシェイクで提供されることがあり得ます（MAY）。

コア QUIC プロトコルに関する接続レベルのオプションは初期の暗号ハンドシェイクで設定されますが、HTTP/3 固有の設定は SETTINGS フレームで伝達されます。QUIC 接続が確立された後、各エンドポイントはそれぞれの HTTP control stream の初期フレームとして SETTINGS フレームを送信しなければなりません（MUST）。

HTTP/3 接続は複数のリクエストにわたって持続します。最高のパフォーマンスのため、クライアントは追加のサーバとの通信が不要であると判断されるまで（例えばユーザが特定のウェブページから離れるとき）接続を閉じないことが期待されます、またはサーバが接続を閉じるまで保持します。

一度サーバエンドポイントへの接続が存在すると、その接続は複数の異なる URI authority コンポーネントを持つリクエストに再利用されることがあります（MAY）。新しいオリジンのために既存接続を使用するには、クライアントはサーバが新しいオリジンに提示した証明書を Section 4.3.4 のプロセスを用いて検証しなければなりません（MUST）。これはクライアントがサーバ証明書とその証明書を検証するために必要な追加情報を保持する必要があることを意味します；そうしないクライアントは接続を追加のオリジンで再利用することができません。

証明書が何らかの理由で新しいオリジンに対して受け入れられない場合、接続は再利用してはならず（MUST NOT）、新しいオリジンのために新しい接続を確立すべきです（SHOULD）。証明書の検証が失敗する理由がその接続に関連付けられた他のオリジンにも当てはまる可能性がある場合、クライアントはそれらのオリジンに対してもサーバ証明書を再検証すべきです（SHOULD）。例えば、証明書の検証が有効期限切れや失効のために失敗した場合、その証明書が権限確立に使用された他のすべてのオリジンも無効にされるかもしれません。

クライアントは与えられた IP アドレスと UDP ポートに対して複数の HTTP/3 接続を開いてはならない（SHOULD NOT）。ここで IP アドレスとポートは URI、選択された代替サービス（[ALTSVC]）、設定されたプロキシ、またはそれらの名前解決に由来する可能性があります。クライアントは異なるトランスポート或いは TLS 構成を用いることで同じ IP アドレスと UDP ポートに複数の HTTP/3 接続を開くことができます（MAY）が、同一の構成で複数の接続を作成することは避けるべきです（SHOULD）。

サーバは可能な限り長く HTTP/3 接続を維持することが奨励されますが、必要に応じてアイドル接続を終了することが許可されます。いずれかのエンドポイントが HTTP/3 接続を閉じることを選択する場合、終了するエンドポイントはまず GOAWAY フレーム（Section 5.2）を送信するべきです（SHOULD）。これにより両エンドポイントは以前に送信されたフレームが処理されたかどうかを確実に判断し、必要な残作業を優雅に完了または終了できます。

サーバが特定のオリジンに対してクライアントが接続を再利用することを望まない場合、サーバはリクエストに対して 421 (Misdirected Request) ステータスコードを返すことで、そのリクエストに対して権威がないことを示すことができます；詳細は Section 7.4 の [HTTP] を参照してください。

クライアントは リクエストストリーム 上で HTTP リクエストを送信します。これはクライアントが開始する双方向の QUIC ストリームです（Section 6.1 を参照）。クライアントは特定のストリーム上で単一のリクエストのみを送信しなければなりません（MUST）。サーバは同じストリーム上で 0 個以上の中間的な HTTP レスポンスを送信し、その後に単一の最終 HTTP レスポンスを送信します。中間応答と最終応答の説明は Section 15 の [HTTP] を参照してください。

プッシュされた応答はサーバが開始する一方向の QUIC ストリーム上で送信されます（Section 6.2.2 を参照）。サーバは通常の応答と同様に、0 個以上の中間的な HTTP レスポンスに続いて単一の最終 HTTP レスポンスを送信します。プッシュの詳細は Section 4.6 を参照してください。

あるストリーム上で複数のリクエストを受信した場合、あるいは最終 HTTP レスポンスの後に追加の HTTP レスポンスを受信した場合は、それを 不正（malformed） として扱わなければなりません（MUST）。

1. メッセージ制御データを含むヘッダセクションを単一の HEADERS フレームとして送信すること、
2. （存在する場合）コンテンツを一連の DATA フレームとして送信すること（任意）、および
3. （存在する場合）トレーラセクションを単一の HEADERS フレームとして送信すること（任意）。

ヘッダおよびトレーラセクションの説明は Section 6.3 および Section 6.5 の [HTTP] を参照してください。コンテンツは Section 6.4 に記述されています。

フレームの不正な順序の受信は、接続エラー として扱わなければなりません（MUST）。特に、いかなる HEADERS フレームの前に DATA フレームが来ること、またはトレーリングの HEADERS フレームの後に HEADERS や DATA フレームが来ることは無効と見なされます。他のフレームタイプ、特に不明なフレームタイプについてはそれぞれの規則に従って許容される場合があります。詳細は Section 9 を参照してください。

サーバは応答メッセージのフレームの前、後、またはそれらとインターリーブして 1 個以上の PUSH_PROMISE フレームを送信することができます（MAY）。これらの PUSH_PROMISE フレームは応答の一部ではありません。詳細は Section 4.6 を参照してください。PUSH_PROMISE フレームは プッシュストリーム 上で許可されていません。もしプッシュされた応答が PUSH_PROMISE フレームを含む場合、それは 接続エラー として扱われ、タイプは H3_FRAME_UNEXPECTED でなければなりません（MUST）。

不明なタイプのフレーム（Section 9 を含む）、および予約されたフレーム（Section 7.2.8）は、要求または プッシュストリーム 上で、ここで説明される他のフレームの前後またはインターリーブして送信されることができます（MAY）。

HEADERS および PUSH_PROMISE フレームは QPACK 動的テーブルへの更新を参照することがあります。これらの更新はメッセージ交換の直接の一部ではありませんが、メッセージを消費する前に受信および処理されなければなりません。詳細は Section 4.2 を参照してください。

転送符号化（Transfer codings；Section 7 の説明）は HTTP/3 では定義されていません。Transfer-Encoding ヘッダフィールドは使用してはなりません（MUST NOT）。

応答が複数のメッセージで構成され得るのは、同一のリクエストに対して 1 個以上の中間応答（1xx；Section 15.2 を参照）が最終応答に先行する場合に限られます（この場合にのみ）。中間応答はコンテンツやトレーラセクションを含みません（MAY はここでは不要）。

HTTP のリクエスト/レスポンス交換はクライアント開始の双方向 QUIC ストリームを完全に消費します。リクエストを送信した後、クライアントは送信側のストリームを閉じなければなりません（MUST）。CONNECT メソッドを使用する場合（Section 4.4 を参照）を除き、クライアントはレスポンスを受信することに依存してストリームのクローズを行ってはなりません（MUST NOT）。最終レスポンスを送信した後、サーバは送信側のストリームを閉じなければなりません（MUST）。この時点で QUIC ストリームは完全に閉じられます。

ストリームが閉じられると、それは最終 HTTP メッセージの終了を示します。メッセージによっては大きいか無限であるため、エンドポイントはメッセージの一部が十分に受信されて処理を進められるようになった時点で部分的な HTTP メッセージの処理を開始すべきです（SHOULD）。もしクライアント開始ストリームが HTTP メッセージの十分な部分を受信せずに終了した場合、サーバはエラーコード H3_REQUEST_INCOMPLETE で応答ストリームを中止すべきです（SHOULD）。

サーバは、応答が未送信のリクエスト部分に依存しない場合、クライアントがリクエスト全体を送信する前に完全な応答を送信することができます。サーバが残りのリクエストを受け取る必要がない場合、サーバは リクエストストリーム の読み取りを中止し、完全な応答を送信し、送信側をクリーンに閉じることができます。このときクライアントに対してストリームの送信を停止するよう要求する際にはエラーコード H3_NO_ERROR を使用することが推奨されます（SHOULD）。クライアントは、リクエストが突然終了した結果として完全な応答を破棄してはなりません（MUST NOT）。ただし、クライアントは他の理由で任意に応答を破棄することはできます。もしサーバが部分的または完全な応答を送信したがリクエストの読み取りを中止しなかった場合、クライアントはリクエストのコンテンツの送信を続け、通常どおりストリームを閉じるべきです（SHOULD）。

HTTP メッセージは "HTTP フィールド" と呼ばれるキー・バリューの列としてメタデータを運びます。詳細は Section 6.3 および Section 6.5 の [HTTP] を参照してください。登録された HTTP フィールドの一覧は IANA の "Hypertext Transfer Protocol (HTTP) Field Name Registry"（<https://www.iana.org/assignments/http-fields/>）で参照できます。HTTP/2 と同様に、HTTP/3 ではフィールド名で使用できる文字、Connection ヘッダフィールド、擬似ヘッダフィールドに関して追加の考慮事項があります。

フィールド名は ASCII 文字の部分集合を含む文字列です。HTTP フィールド名と値の性質については Section 5.1 を参照してください。フィールド名の文字はエンコードの前に小文字に変換されなければなりません（MUST）。フィールド名に大文字が含まれるリクエストまたはレスポンスは不正と見なされます（malformed）（MUST）。

HTTP/3 は Connection ヘッダフィールドを接続固有のフィールドを示すために使用しません。本プロトコルでは接続固有のメタデータは他の手段で伝達されます。エンドポイントは接続固有のフィールドを含む HTTP/3 フィールドセクションを生成してはなりません（MUST NOT）。接続固有のフィールドを含むメッセージは不正として扱われます（MUST）。

ただし例外として TE ヘッダフィールドは HTTP/3 リクエストヘッダに含まれてもよく（MAY）、存在する場合は "trailers" 以外の値を含んではなりません（MUST NOT）。

HTTP/1.x メッセージを HTTP/3 に変換するインターミディアリは、Connection 固有のヘッダフィールドを削除しなければなりません（Section 7.6.1 を参照）。削除しないと、他の HTTP/3 エンドポイントによってそのメッセージは不正として扱われます。

HTTP/2 と同様に、HTTP/3 もフィールド名が : 文字（ASCII 0x3a）で始まる擬似ヘッダフィールドの列を使用します。これらの擬似ヘッダフィールドはメッセージ制御データを伝達します。詳細は Section 6.2 を参照してください。

擬似ヘッダフィールドは HTTP フィールドではありません。エンドポイントは本書で定義されたもの以外の擬似ヘッダフィールドを生成してはなりません（MUST NOT）。ただし、拡張によりこの制限の修正が交渉され得ることがあります。詳細は Section 9 を参照してください。

擬似ヘッダフィールドはそれが定義されている文脈でのみ有効です。リクエスト用に定義された擬似ヘッダフィールドはレスポンスに現れてはならず（MUST NOT）、レスポンス用に定義された擬似ヘッダフィールドはリクエストに現れてはなりません（MUST NOT）。擬似ヘッダフィールドはトレーラセクションに現れてはなりません（MUST NOT）。定義されていないか無効な擬似ヘッダフィールドを含むリクエストやレスポンスは不正として扱わなければなりません（MUST）。

すべての擬似ヘッダフィールドは通常のヘッダフィールドより前にヘッダセクション内に現れなければなりません（MUST）。ヘッダセクション内で通常のヘッダの後に擬似ヘッダフィールドが現れるリクエストまたはレスポンスは不正として扱われます（MUST）。

CONNECT メソッドは受信者に対してリクエストターゲットで識別される宛先オリジンサーバへのトンネルを確立するよう要求します。詳細は Section 9.3.6 を参照してください。主に HTTP プロキシで、オリジンサーバとの TLS セッションを確立し "https" リソースとやり取りする目的で使用されます。

HTTP/1.x では CONNECT は全 HTTP 接続をリモートホストへのトンネルに変換するために使われます。HTTP/2 および HTTP/3 では CONNECT メソッドは単一のストリーム上でトンネルを確立するために使用されます。

• :method 擬似ヘッダフィールドは "CONNECT" に設定すること
• :scheme および :path 擬似ヘッダフィールドは省略すること
• :authority 擬似ヘッダフィールドは接続先のホストとポートを含むこと（CONNECT リクエストの request-target の authority-form に相当）

リクエストストリーム は、転送されるデータを運ぶためにリクエストの終わりでも開いたままにしておかなければなりません。これらの制限に従わない CONNECT リクエストは不正です（malformed）。

CONNECT をサポートするプロキシは :authority 擬似ヘッダで識別されたサーバに対して TCP 接続を確立します。接続が成功すると、プロキシはクライアントに対して 2xx 系のステータスコードを含む HEADERS フレームを送信します（定義は Section 15.3 を参照）。

ストリーム上のすべての DATA フレームは TCP 接続上で送受信されるデータに対応します。クライアントが送信する任意の DATA フレームのペイロードはプロキシによって TCP サーバへ転送され、TCP サーバから受信したデータはプロキシによって DATA フレームにパッケージされてクライアントへ送られます。TCP セグメントのサイズと数が HTTP の DATA フレームや QUIC ストリームフレームのサイズと数に予測可能に対応するとは限らないことに注意してください。

CONNECT メソッドが完了した後、そのストリーム上では DATA フレームのみが送信可能です。拡張が明示的に許可する場合に限り拡張フレームを使用できます。その他の既知のフレームタイプを受信した場合は、接続エラーとして扱われ、タイプは H3_FRAME_UNEXPECTED でなければなりません（MUST）。

TCP 接続はどちらのピアによっても閉じられ得ます。クライアントが リクエストストリーム を終了すると（すなわちプロキシでの受信ストリームが "Data Recvd" 状態になると）、プロキシは TCP サーバへの接続で FIN ビットを設定します。プロキシが FIN ビットを含むパケットを受信すると、クライアントへ送る送信ストリームを閉じます。片方向で半クローズのままの TCP 接続は無効ではありませんが、サーバによっては適切に扱われないことが多いため、クライアントはまだ CONNECT の対象からデータを受信することを期待している間に送信側のストリームを閉じるべきではありません（SHOULD NOT）。

TCP の 接続エラー はストリームを突然終了することで通知されます。プロキシは TCP 接続上のあらゆるエラー（RST ビットを含む TCP セグメントの受信を含む）を ストリームエラー として扱い、タイプは H3_CONNECT_ERROR とします。

逆に、プロキシがストリームや QUIC 接続にエラーを検出した場合、TCP 接続を閉じなければなりません（MUST）。クライアントがストリームをリセットしたり読み取りを中止したことをプロキシが検出した場合も、プロキシは TCP 接続を閉じなければなりません（MUST）。もしクライアントによってストリームがリセットされたり読み取りが中止された場合、プロキシは可能ならばストリームの他方向についても同じ操作を行って両方向をキャンセルすることが推奨されます（SHOULD）。これらの場合、基盤となる TCP 実装が許すならば、プロキシは RST ビットを立てた TCP セグメントを送信することが推奨されます（SHOULD）。

CONNECT は任意のサーバへのトンネルを作成するため、CONNECT をサポートするプロキシはその使用を既知のポートの集合または安全なリクエストターゲットのリストに制限することが推奨されます（SHOULD）。詳細は Section 9.3.6 を参照してください。

HTTP/3 は HTTP Upgrade の仕組みをサポートしません（詳細は Section 7.8 を参照）。また 101 (Switching Protocols) 情報ステータスコードもサポートしません（Section 15.2.2 を参照）。

サーバープッシュは、サーバがクライアントが行うであろうリクエストを予測してリクエスト・レスポンス交換をクライアントへプッシュすることを許すインタラクションモードです。これはネットワーク使用量と潜在的なレイテンシ利得とのトレードオフです。HTTP/3 のサーバープッシュは Section 8.2 に記述されたものに類似していますが、異なるメカニズムを使用します。

各サーバープッシュにはサーバによって一意な push ID が割り当てられます。push ID は HTTP/3 接続のライフタイムを通じて様々な文脈でそのプッシュを参照するために使用されます。

push ID 空間は 0 から始まり、MAX_PUSH_ID フレームで設定される最大値で終わります。特に、クライアントが MAX_PUSH_ID フレームを送信するまではサーバはプッシュできません。クライアントはサーバが約束できるプッシュの数を制御するために MAX_PUSH_ID フレームを送信します。サーバは push ID を 0 から順に連番で使用することが推奨されます（SHOULD）。クライアントは プッシュストリーム を、MAX_PUSH_ID フレームが送信されていない場合、あるいはストリームが最大 push ID を超える push ID を参照する場合に、接続エラー（タイプ H3_ID_ERROR）として扱わなければなりません（MUST）。

push ID は、リクエストメッセージの制御データおよびヘッダフィールドを運ぶ 1 個以上の PUSH_PROMISE フレームで使用されます。これらのフレームはプッシュを生成した リクエストストリーム 上で送信されます。これによりサーバープッシュをクライアントリクエストと関連付けることができます。同じ push ID が複数の リクエストストリーム 上で約束される場合、展開されたリクエストフィールドセクションは同じ順序で同じフィールドを含まなければならず、各フィールドの名前と値は完全に一致しなければなりません（MUST）。

その後、push ID は最終的にこれらの約束を履行する プッシュストリーム に含まれます。プッシュストリーム は、それが履行する約束の push ID を識別し、次に Section 4.1 に記述されたように約束されたリクエストへのレスポンスを含みます。

最後に、push ID は CANCEL_PUSH フレームで使用できます（Section 7.2.3 を参照）。クライアントはこのフレームを使用して約束されたリソースを受け取りたくないことを示し、サーバはこのフレームを使用して以前の約束を履行しないことを示します。

• キャッシュ可能であること（詳細は Section 9.2.3 を参照）
• 安全であること（詳細は Section 9.2.1 を参照）
• リクエストコンテンツやトレーラセクションを含まないこと

サーバは自らが権限を持つ :authority 擬似ヘッダの値を含めなければなりません（MUST）。もしクライアントがそのプッシュされたリクエストで示されたオリジンに対してまだ接続の検証を行っていない場合、クライアントはそのオリジンに対してリクエストをその接続上で送信する前に行うのと同じ検証プロセスを実行しなければなりません（Section 3.3 を参照）。この検証に失敗した場合、クライアントはそのサーバを当該オリジンの権威あるサーバと見なしてはなりません（MUST NOT）。

クライアントは、受信した PUSH_PROMISE フレームで示されたリクエストがキャッシュ可能でない、既知で安全でない、リクエストコンテンツの存在を示す、あるいはサーバをそのリクエストのオーソリティと見なさない場合、CANCEL_PUSH フレームを送信するべきです（SHOULD）。対応する応答は使用またはキャッシュしてはなりません（MUST NOT）。

各プッシュされた応答は 1 個以上のクライアントリクエストに関連付けられます。プッシュは、PUSH_PROMISE フレームが受信された リクエストストリーム に関連付けられます。同じサーバープッシュは、同じ push ID を持つ別の PUSH_PROMISE フレームを複数の リクエストストリーム 上で送ることで追加のクライアントリクエストに関連付けられることがあります。これらの関連付けはプロトコルの動作には影響しませんが、ユーザエージェントがプッシュされたリソースの利用方法を決める際に考慮され得ます（MAY）。

PUSH_PROMISE フレームと応答の特定部分との順序は重要です。サーバは約束された応答を参照する HEADERS または DATA フレームを送信する前に PUSH_PROMISE フレームを送信することが推奨されます（SHOULD）。これによりクライアントがサーバがプッシュするリソースを不必要に要求する可能性が減ります。

再順序により、プッシュストリーム のデータが対応する PUSH_PROMISE フレームより先に到着することがあります。クライアントが未知の push ID を持つ新しい プッシュストリーム を受信した場合、関連するクライアントリクエストとプッシュされたリクエストのヘッダフィールドは不明です。クライアントは一致する PUSH_PROMISE フレームを期待してストリームデータをバッファすることができます。クライアントはストリームフロー制御を用いてサーバがプッシュストリームにコミットできるデータ量を制限することができます。もし妥当な時間内に対応する PUSH_PROMISE フレームが処理されない場合、クライアントは プッシュストリーム の読み取りを中止して既に読んだデータを破棄するべきです（SHOULD）。

クライアントがプッシュをキャンセルした後にプッシュストリームデータが到着することもあります。この場合、クライアントは H3_REQUEST_CANCELLED のエラーコードで読み取りを中止することができます。これによりサーバに追加データの送信をやめるよう要求し、受信したデータは破棄されることを示します。

キャッシュ可能なプッシュされた応答は、クライアントが HTTP キャッシュを実装している場合にクライアントによって保存され得ます（詳細は Section 3 を参照）。プッシュされた応答は、受信時点でオリジンサーバ上で成功裏に検証されたと見なされます（例えば "no-cache" 指示子がある場合など）。

キャッシュ可能でないプッシュされた応答はどの HTTP キャッシュによっても格納してはなりません（MUST NOT）。ただし、これらはアプリケーションに別個に提供され得ます（MAY）。

各 QUIC エンドポイントはハンドシェイク中にアイドルタイムアウトを宣言します。QUIC 接続がこの期間より長くアイドルのままである（パケットを受信しない）場合、ピアは接続が閉じられたと見なします。HTTP/3 実装は、既存の接続が QUIC ハンドシェイク中に交渉されたアイドルタイムアウトより長くアイドルであった場合、新しいリクエストのために新しい HTTP/3 接続を開く必要があり、アイドルタイムアウトに近づいている場合はそのようにすることが推奨されます（SHOULD）。詳細は Section 10.1 を参照してください（[QUIC-TRANSPORT]）。

HTTP クライアントは、リクエストに対してレスポンスやサーバプッシュが保留中の間はトランスポートに接続を維持するよう要求することが期待されます（詳細は Section 10.1.2 を参照）。クライアントがサーバからの応答を期待していない場合、必要ないかもしれない接続を維持する努力をするよりも、アイドル接続をタイムアウトさせることが望ましいです。ゲートウェイは、サーバへの接続確立の遅延コストを回避するために、必要を見越して接続を維持することが MAY あります。サーバは接続を積極的に維持すべきではありません（SHOULD NOT）。

接続がアイドルでない場合でも、いずれのエンドポイントも接続の使用を停止して優雅な接続終了を開始することができます。エンドポイントは GOAWAY フレームを送信することで HTTP/3 接続の優雅なシャットダウンを開始します。GOAWAY フレームは、受信者に対してこの接続で処理されたかもしれないリクエストやプッシュの範囲を示す識別子を含みます。サーバはクライアント開始の双方向ストリーム ID を送信し、クライアントは push ID を送信します。示された識別子以上の識別子を持つリクエストまたはプッシュは、GOAWAY の送信者によって拒否されます（Section 4.1.1 を参照）。処理されたリクエストやプッシュがない場合、この識別子は 0 であってもかまいません（MAY）。

GOAWAY フレーム内の情報により、クライアントとサーバは HTTP/3 接続のシャットダウン前にどのリクエストやプッシュが受け入れられたかを合意できます。GOAWAY フレームを送信した後、エンドポイントは示された識別子以上の識別子を持つリクエストやプッシュを明示的にキャンセルすることが SHOULD です（状態のクリーンアップのため、Section 4.1.1 および 7.2.3 を参照）。エンドポイントは、さらにリクエストやプッシュが到着するにつれてこれを継続すべきです（SHOULD）。

ピアから GOAWAY フレームを受信した後、エンドポイントは接続上で新しいリクエストを開始したり新しいプッシュを約束したりしてはなりません（MUST NOT）。クライアントは追加のリクエストを送信するために新しい接続を確立してもかまいません（MAY）。

• GOAWAY フレームを受信した際、もしクライアントがすでにその GOAWAY フレームに含まれる識別子以上のストリーム ID を持つリクエストを送信している場合、それらのリクエストは処理されません。クライアントは処理されなかったリクエストを別の HTTP 接続上で安全に再試行できます。再試行できないクライアントは、サーバが接続を閉じた時点で転送中のすべてのリクエストを失います。

  サーバからの GOAWAY フレームのストリーム ID より小さいストリーム ID 上のリクエストは処理されている可能性があります。これらの状態は、レスポンスが受信されるまで、ストリームが個別にリセットされるまで、より小さいストリーム ID を持つ別の GOAWAY が受信されるまで、または接続が終了するまで判明しないことがあります。

  サーバは、示された ID 未満のストリーム上の個々のリクエストを処理していなかった場合にそれらを拒否することが MAY あります。

• サーバが GOAWAY フレームを受信した後に、フレームに含まれる識別子以上の push ID を伴うプッシュを約束していた場合、それらのプッシュは受け入れられません。

サーバは接続の閉鎖が事前に判明している場合、たとえその事前通知が短くても、リモートピアがどのリクエストに部分的に処理が行われたかを知ることができるように GOAWAY フレームを送信することが SHOULD です。たとえば、HTTP クライアントが POST を送信しているタイミングでサーバが QUIC 接続を閉じるとき、サーバがどのストリームに作用したかを示す GOAWAY フレームを送信しないと、クライアントはサーバが POST の処理を開始したかどうかを知ることができません。

エンドポイントは異なる識別子を示す複数の GOAWAY フレームを送信することが MAY ありますが、各フレームの識別子は以前のフレームの識別子より大きくしてはなりません（クライアントは処理されなかったリクエストを既に別の接続で再試行している可能性があるため）。以前に受信したものより大きい識別子を含む GOAWAY を受信した場合、それは 接続エラー として扱われ、タイプは H3_ID_ERROR でなければなりません（MUST）。

優雅に接続をシャットダウンしようとするエンドポイントは、最大値に設定された値（サーバは 2⁶²-4、クライアントは 2⁶²-1）を持つ GOAWAY フレームを送信することができます。これによりピアは新しいリクエストやプッシュを作成するのを停止します。転送中のリクエストやプッシュが到着する時間を与えた後、エンドポイントは接続終了前に受け入れ得るリクエストやプッシュを示す別の GOAWAY フレームを送信できます。これによりリクエストを失うことなく接続をクリーンに終了できるようになります。

クライアントは自身が送信する GOAWAY の Push ID フィールドの値についてより柔軟に選択できます。値 2⁶²-1 はサーバが既に約束されたプッシュの履行を継続できることを示します。より小さい値は、クライアントがこの値以上の push ID を持つプッシュを拒否することを示します。サーバと同様に、クライアントは指定された push ID が以前に送信した値より大きくない限り、その後にさらに GOAWAY フレームを送信することが MAY あります。

GOAWAY が特定のリクエストやプッシュが処理または受け入れられないことを示している場合でも、基盤となるトランスポート資源はまだ存在します。これらのリクエストを開始したエンドポイントは、トランスポート状態をクリーンにするためにそれらをキャンセルできます。

受け入れられたすべてのリクエストとプッシュが処理されると、エンドポイントは接続をアイドルにすることを許可するか、または即時に接続を閉じることが MAY あります。優雅なシャットダウンを完了したエンドポイントは、接続を閉じる際に H3_NO_ERROR エラーコードを使用することが SHOULD です。

クライアントがリクエスト用の双方向ストリーム ID をすべて使い切っている場合、サーバは GOAWAY フレームを送信する必要はありません。クライアントはそれ以上リクエストを行うことができないためです。

HTTP/3 実装はいつでも QUIC 接続を即時に閉じることができます。これにより、アプリケーション層が接続を終了したことを示す QUIC CONNECTION_CLOSE フレームがピアに送信されます。このフレーム内のアプリケーションエラーコードは、接続がなぜ閉じられるのかをピアに示します。接続を閉じる際に使用できるエラーコードについては Section 8 を参照してください。

接続を閉じる前に、クライアントがいくつかのリクエストを再試行できるように GOAWAY フレームを送信することが MAY あります。QUIC CONNECTION_CLOSE フレームと同じパケットに GOAWAY フレームを含めると、クライアントがそのフレームを受信する確率が高まります。

明示的に閉じられていない開いたストリームがある場合、それらは接続が閉じられると暗黙的に閉じられます。詳細は Section 10.2 を参照してください（[QUIC-TRANSPORT]）。

さまざまな理由により、QUIC トランスポートはアプリケーション層に接続が終了したことを通知する可能性があります。これは、ピアによる明示的な閉鎖、トランスポートレベルのエラー、または接続を中断するネットワークトポロジーの変化によるものかもしれません。

接続が GOAWAY フレームなしで終了した場合、クライアントは送信されたあらゆるリクエスト（全部または一部）が処理された可能性があるものとみなさなければなりません（MUST）。

クライアント開始のすべての双方向ストリームは HTTP リクエストとレスポンスに使用されます。双方向ストリームはレスポンスをリクエストと容易に関連付けられることを保証します。これらのストリームはリクエストストリームと呼ばれます。

これはクライアントの最初のリクエストが QUIC ストリーム 0 上で行われ、続くリクエストはストリーム 4、8、… 上で行われることを意味します。これらのストリームを開けるように、HTTP/3 サーバは許可されるストリーム数および初期ストリームフロー制御ウィンドウの最小値をゼロ以外に構成することが SHOULD です。並列性を不必要に制限しないために、少なくとも 100 のリクエストストリームが同時に許可されることが SHOULD です。

HTTP/3 はサーバ開始の双方向ストリームを使用しませんが、拡張がこれらのストリームの使用を定義することがあり得ます。そのような拡張が交渉されていない限り、クライアントはサーバ開始の双方向ストリームを受信した場合、それを 接続エラー として扱い、タイプは H3_STREAM_CREATION_ERROR でなければなりません（MUST）。

一方向ストリームは、いずれの方向でもさまざまな目的に使用されます。目的はストリームの先頭で可変長整数として送信されるストリームタイプによって示されます。この整数の後に続くデータの形式と構造はストリームタイプによって決まります。

本書では 2 つのストリームタイプが定義されています：control streams（Section 6.2.1）および push streams（Section 6.2.2）。[QPACK] は 2 つの追加のストリームタイプを定義します。その他のストリームタイプは HTTP/3 の拡張によって定義できます；詳細は Section 9 を参照してください。いくつかのストリームタイプは予約されています（Section 6.2.3）。

HTTP/3 接続の初期段階におけるパフォーマンスは、一方向ストリーム上でのデータの作成と交換に敏感です。エンドポイントがストリーム数やこれらのストリームのフロー制御ウィンドウを過度に制限すると、リモートピアが早期に上限に達してブロックされる可能性が高まります。特に、実装はリモートピアが許可された一方向ストリームの一部で予約済みストリーム動作（Section 6.2.3）を行使するかもしれないことを考慮すべきです。

各エンドポイントは HTTP の control stream のために少なくとも 1 つの一方向ストリームを作成する必要があります。QPACK はさらに 2 つの一方向ストリームを必要とし、他の拡張は追加のストリームを必要とする場合があります。したがって、クライアントとサーバが送信するトランスポートパラメータはピアが少なくとも 3 個の一方向ストリームを作成できることを許可しなければなりません（MUST）。これらのトランスポートパラメータは各一方向ストリームに少なくとも 1,024 バイトのフロー制御クレジットを提供することが推奨されます（SHOULD）。

ピアが重要な一方向ストリームを作成する前に初期クレジットをすべて消費してしまった場合、エンドポイントがさらに一方向ストリームを作成するための追加クレジットを付与する必要はないことに注意してください。エンドポイントは HTTP の control stream および必須拡張（例えば QPACK エンコーダとデコーダストリーム）で要求される一方向ストリームをまず作成し、その後ピアが許可する範囲で追加のストリームを作成することが SHOULD です。

ストリームヘッダが受信者によってサポートされないストリームタイプを示す場合、その後のストリームの残りは意味が不明なため消費できません。不明なストリームタイプの受信者はストリームの読み取りを中止するか、受信データをさらなる処理なしに破棄しなければなりません（MUST）。読み取りを中止する場合、受信者は H3_STREAM_CREATION_ERROR エラーコードまたは予約済みエラーコードを使用することが推奨されます（SHOULD）。受信者は不明なストリームタイプを接続エラーと見なしてはなりません（MUST NOT）。

特定のストリームタイプが接続状態に影響を与える可能性があるため、受信者はストリームタイプを読む前に受信した一方向ストリームのデータを破棄しないことが SHOULD NOT です。

実装はピアがそれらをサポートするかどうかを知らないうちにストリームタイプを送信することが MAY です。しかし、QPACK や他の拡張を含む既存のプロトコルコンポーネントの状態や意味を変更する可能性があるストリームタイプは、ピアがそれらをサポートすると判明するまで送信してはなりません（MUST NOT）。

送信者は、特に指定がない限り、一方向ストリームを閉じたりリセットしたりできます。受信者は一方向ストリームヘッダの受信前にストリームが閉じられたりリセットされたりすることを許容しなければなりません（MUST）。

Type:

フレームタイプを識別する可変長整数。

Length:

フレームペイロードのバイト長を示す可変長整数。

Frame Payload:

Type フィールドによって意味が決まるペイロード。

各フレームのペイロードは、その説明に記載されたフィールドを正確に含まなければなりません（MUST）。識別されたフィールドの末尾より追加のバイトを含むフレームペイロード、または識別されたフィールドの終わりより前に終端するフレームペイロードは、接続エラー として扱われ、タイプは H3_FRAME_ERROR でなければなりません（MUST）。特に、冗長な長さエンコーディングは自己整合性を検証する必要があります。詳細は Section 10.8 を参照してください。

ストリームがクリーンに終了したとき、もしストリーム上の最後のフレームが切り詰められていた場合、それは 接続エラー として扱われ、タイプは H3_FRAME_ERROR でなければなりません。突然終了したストリームはフレームのどの時点でもリセットされ得ます。

次のエラーコードは、ストリームの突然の終了、ストリームの読み取り中止、または HTTP/3 接続の即時閉鎖時に使用するために定義されています。

H3_NO_ERROR (0x0100)

:

エラーなし。接続またはストリームを閉じる必要があるが、特に示すべきエラーがない場合に使用されます。

H3_GENERAL_PROTOCOL_ERROR (0x0101)

:

ピアがより具体的なエラーコードに該当しない形でプロトコル要件に違反したか、エンドポイントがより具体的なエラーコードを使用しないことを選択した場合。

H3_INTERNAL_ERROR (0x0102)

:

HTTP スタック内で内部エラーが発生したことを示します。

H3_STREAM_CREATION_ERROR (0x0103)

:

ピアが作成したストリームを受け入れないと検出したことを示します。

H3_CLOSED_CRITICAL_STREAM (0x0104)

:

HTTP/3 接続で必要とされるストリームが閉じられたりリセットされたことを示します。

H3_FRAME_UNEXPECTED (0x0105)

:

現在の状態や当該ストリームで許可されていないフレームが受信されたことを示します。

H3_FRAME_ERROR (0x0106)

:

レイアウト要件を満たさない、または無効なサイズのフレームが受信されたことを示します。

H3_EXCESSIVE_LOAD (0x0107)

:

ピアが過度の負荷を発生させている可能性のある挙動を示したことを検出した場合に使用します。

H3_ID_ERROR (0x0108)

:

ストリーム ID や push ID が誤用された（例えば上限を超えた、上限を下げた、再利用された等）場合に使用します。

H3_SETTINGS_ERROR (0x0109)

:

SETTINGS フレームのペイロードにエラーを検出した場合に使用します。

H3_MISSING_SETTINGS (0x010a)

:

SETTINGS フレームが control stream の開始時に受信されなかったことを示します。

H3_REQUEST_REJECTED (0x010b)

:

サーバがアプリケーション処理を一切行わずにリクエストを拒否したことを示します。

H3_REQUEST_CANCELLED (0x010c)

:

リクエストまたはそのレスポンス（プッシュされたレスポンスを含む）がキャンセルされたことを示します。

H3_REQUEST_INCOMPLETE (0x010d)

:

クライアントのストリームが完全なリクエストを含まないまま終了したことを示します。

H3_MESSAGE_ERROR (0x010e)

:

HTTP メッセージが malformed であり処理できないことを示します。

H3_CONNECT_ERROR (0x010f)

:

CONNECT リクエストに応じて確立された TCP 接続がリセットされたか異常終了したことを示します。

H3_VERSION_FALLBACK (0x0110)

:

要求された操作は HTTP/3 では提供できません。ピアは HTTP/1.1 で再試行すべきです。

エラーコード空間のうち 0x1f * N + 0x21（非負整数 N）の形式は、未知のエラーコードが H3_NO_ERROR と同等に扱われることを行使するために予約されています（Section 9 を参照）。実装は H3_NO_ERROR を送る代わりに、この空間から確率的にエラーコードを選択することが SHOULD あります。

HTTP/3 は権威に関する HTTP の定義に依存します。権威を確立する際のセキュリティ上の考慮事項は Section 17.1 の [HTTP] で議論されています。

TLS および QUIC ハンドシェイクでの ALPN の使用により、アプリケーション層のバイトが処理される前にターゲットアプリケーションプロトコルが確立されます。これにより、ピアが同じプロトコルを使用しているという強い保証が得られます。

これはすべてのプロトコル間攻撃からの保護を保証するものではありません。Section 21.5 は、QUIC パケットの平文が認証されないトランスポートを使用するエンドポイントに対するリクエスト偽造にどのように利用され得るかを説明しています（[QUIC-TRANSPORT]）。

HTTP/3 のフィールドエンコーディングは、HTTP の構文（Section 5.1 の定義）では有効でない名前を表現することを許します。無効なフィールド名を含むリクエストやレスポンスは MUST malformed として扱われます。したがって、中間者は無効なフィールド名を含む HTTP/3 リクエストやレスポンスを HTTP/1.1 メッセージに変換することはできません。

同様に、HTTP/3 は有効でないフィールド値も運ぶことができます。多くのエンコード可能な値はフィールドの解析を変えませんが、復帰（ASCII 0x0d）、改行（ASCII 0x0a）、およびヌル文字（ASCII 0x00）は、逐語的に翻訳された場合に攻撃者に悪用され得ます。フィールド値で許可されない文字を含むリクエストやレスポンスは MUST malformed として扱われます。有効な文字は Section 5.5 の "field-content" ABNF ルールで定義されています（[HTTP]）。

プッシュされたレスポンスはクライアントからの明示的なリクエストを持ちません；リクエストはサーバが PUSH_PROMISE フレームで提供します。

プッシュされたレスポンスのキャッシュは、Cache-Control ヘッダフィールドでオリジンサーバが提供する指針に基づいて可能です。しかし、単一のサーバが複数のテナントをホストしている場合は問題を引き起こす可能性があります。例えば、サーバが複数のユーザにそれぞれ小さな URI 空間を提供している場合などです。

複数のテナントが同一サーバ空間を共有する場合、そのサーバはテナントが権限を持たないリソースの表現をプッシュできないようにする必要があります（MUST）。これを怠ると、テナントがキャッシュから提供される表現を上書きしてしまう可能性があります。

クライアントは、オリジンサーバが権威がないプッシュされたレスポンスを拒否する必要があります。詳細は Section 4.6 を参照してください。

HTTP/3 接続は HTTP/1.1 や HTTP/2 接続よりも運用により多くのリソースを要求する場合があります。フィールド圧縮やフロー制御の使用は、より多くの状態を保存するためのリソースの確保を必要とします。これらの機能の設定は、これらの機能に対するメモリのコミットを厳密に制限することを保証します。

PUSH_PROMISE フレームの数も同様に制約されます。サーバプッシュを受け入れるクライアントは、同時に発行する push ID の数を制限することを SHOULD です。

処理能力（processing capacity）は状態容量（state capacity）ほど効果的に守ることができません。

ピアが無視するよう要求される未定義のプロトコル要素を送信する能力は、ピアに追加の処理時間を費やさせるために悪用され得ます。これは複数の未定義 SETTINGS パラメータ、未知のフレームタイプ、未知のストリームタイプを設定することで行われるかもしれません。ただし、オプションとして理解される拡張やトラフィック解析への抵抗を高めるためのパディングのような正当な使用も存在することに注意してください。

フィールドセクションの圧縮も処理資源を浪費する機会を提供します。詳細は Section 7 の [QPACK] を参照してください。

これらすべての機能――サーバプッシュ、未知のプロトコル要素、フィールド圧縮――には正当な使用法があります。これらの機能は、不必要または過度に使用される場合にのみ負担になります。

このような挙動を監視しないエンドポイントはサービス拒否攻撃のリスクにさらされます。実装はこれらの機能の使用を追跡し、使用に制限を設けることを SHOULD です。エンドポイントは疑わしい活動を 接続エラー として H3_EXCESSIVE_LOAD のタイプで扱うことが MAY ありますが、誤判定は有効な接続やリクエストを妨げることになります。

圧縮は、機密データが攻撃者制御下のデータと同じコンテキストで圧縮されるときに攻撃者が機密データを回復することを可能にする場合があります。HTTP/3 はフィールドの圧縮を可能にします（Section 4.2）。以下の懸念は、HTTP の圧縮コンテンツコーディングの使用にも適用されます。詳しくは Section 8.4.1 を参照してください（[HTTP]）。

Web の特性を悪用する圧縮に対する実証的な攻撃が存在します（例えば [BREACH]）。攻撃者は異なるプレーンテキストを含む複数のリクエストを誘発し、それぞれの結果の暗号文の長さを観察します。秘密に関する推測が正しい場合には短くなることを手掛かりにします。

セキュアチャネルで通信する実装は、機密データと攻撃者制御のデータが混在するコンテンツを、別々の圧縮コンテキストを使用しない限り圧縮してはなりません（MUST NOT）。データの出所を確実に判別できない場合は圧縮を使用してはなりません（MUST NOT）。

フィールドセクションの圧縮に関するさらなる考慮事項は [QPACK] に記述されています。

パディングはフレーム内容の正確なサイズを隠すために使用でき、圧縮コンテンツに攻撃者制御の平文と秘密データの両方が含まれるような攻撃（例えば [BREACH]）に対する緩和策として提供されます。

HTTP/2 が PADDING フレームや他のフレームの Padding フィールドを用いてトラフィック解析に対する耐性を高めるのに対し、HTTP/3 はトランスポート層のパディングに依存するか、あるいは 7.2.8 および 6.2.3 で述べた予約済みフレームとストリームタイプを用いることができます。これらのパディング手法は、パディングの粒度、保護対象情報に対するパディングの配置、パケット損失時にパディングが適用されるかどうか、および実装がパディングを制御する方法に関して異なる結果を生みます。

予約済みストリームタイプは、接続がアイドルであってもトラフィックを送信しているように見せかけるために使用できます。HTTP トラフィックはしばしばバーストで発生するため、見かけ上のトラフィックはそのバーストのタイミングや持続時間を隠すのに使えることがあります。とはいえ、そのようなトラフィックも受信者によってフロー制御されるため、受信者が迅速にそれらのストリームを消費して追加のフロー制御クレジットを与えないと、送信者の実トラフィック送信能力を制限してしまう可能性があります。

圧縮に依存する攻撃を緩和するためには、パディングよりも圧縮を無効化または制限する方が望ましい場合があります。

パディングの使用は直感的に期待されるほどの保護を提供しない場合があります。冗長なパディングは逆に有害になる可能性さえあります。最大でも、パディングは観察すべきフレーム数を増やすことで攻撃者が長さ情報を推測するのを困難にするに過ぎません。不適切に実装されたパディングスキームは容易に破られます。特に、予測可能な分布を持つ乱数パディングはほとんど保護を提供しません。同様に、固定サイズにペイロードをパディングすることは、攻撃者がプレーンテキストを制御できる場合に固定境界を越えると情報を暴露します。

いくつかのプロトコル要素はネストされた長さ要素を含み、通常は可変長整数を含む明示的な長さを持つフレームの形を取ります。これは不注意な実装者にとってセキュリティリスクをもたらす可能性があります。実装はフレームの長さがそのフレームが含むフィールドの長さと正確に一致することを MUST 確保しなければなりません。

HTTP/3 での 0-RTT の使用はリプレイ攻撃の危険性を生じさせます。0-RTT を HTTP/3 で使用する場合は、[HTTP-REPLAY] に記述されたアンチリプレイ対策を MUST 適用する必要があります。HTTP/3 に対して [HTTP-REPLAY] を適用する際、TLS 層への参照は QUIC 内で行われるハンドシェイクを指し、アプリケーションデータへの参照はストリームの内容を指します。

特定の HTTP 実装はログ記録やアクセス制御の目的でクライアントアドレスを使用します。QUIC クライアントのアドレスは接続中に変わる可能性がある（将来のバージョンでは複数のアドレスを同時使用することをサポートするかもしれない）ため、そのような実装は関連時にクライアントの現在のアドレスを能動的に取得するか、元のアドレスが変わる可能性を明示的に受け入れる必要があります。

HTTP/3 のいくつかの特性は、観測者に単一のクライアントまたはサーバの動作を時間を通じて相関させる機会を与える可能性があります。これには設定値、刺激に対する反応のタイミング、および設定で制御される機能の扱いが含まれます。

これらが振る舞いに観察可能な差異を生じさせる限り、それらは特定のクライアントのフィンガープリントを作成する基盤として使用され得ます。

HTTP/3 が単一の QUIC 接続の使用を好むことは、サイト上でのユーザの活動の相関を可能にします。異なるオリジンに対して接続を再利用することは、それらのオリジン間での活動の相関を許します。

QUIC のいくつかの機能は即時の応答を要求し、エンドポイントがピアへの遅延を測定するために使用することができます。これは特定のシナリオでプライバシー上の影響を持ち得ます。

この文書は、"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" レジストリ（[RFC7301]）における HTTP/3 の識別のための新しい登録を作成します。

Protocol:

HTTP/3

Identification Sequence:

0x68 0x33 ("h3")

Specification:

本書

本書で作成される新しいレジストリは、Section 22.1 の QUIC 登録ポリシーに従って運用されます（[QUIC-TRANSPORT]）。これらのレジストリはすべて、Section 22.1.1 に記載された共通フィールド群を含みます（[QUIC-TRANSPORT]）。これらのレジストリは "Hypertext Transfer Protocol version 3 (HTTP/3)" 見出しの下に収集されます。

これらのレジストリの初期割当はすべて恒久的なステータスとして割り当てられ、変更管理者として IETF、および連絡先として HTTP ワーキンググループ（ietf-http-wg@w3.org）が記載されています。

HTTP/3 は HTTP/2 よりも多くのストリーム（2⁶²-1）を使用可能にします。ストリーム識別子空間の枯渇に関する同様の考慮事項は適用されますが、その空間ははるかに大きいため、接続フロー制御ウィンドウの上限など QUIC の他の制限に先に到達する可能性が高くなります。

HTTP/2 と対照的に、HTTP/3 のストリームの同時性は QUIC によって管理されます。QUIC はすべてのデータが受信され送信データがピアによって確認応答されるとストリームが閉じられたと見なします。HTTP/2 は END_STREAM ビットを含むフレームがトランスポートにコミットされたときにストリームが閉じられたと見なします。その結果、同等の交換のためのストリームがより長い期間「アクティブ」のままになる可能性があります。HTTP/3 サーバは、期待される使用パターンに応じて HTTP/2 と同等の並列性を達成するために、クライアント開始の双方向ストリームのより大きな数を許可することを選択するかもしれません。

HTTP/2 では、リクエストおよびレスポンス本体（DATA フレームのペイロード）のみがフロー制御の対象でした。HTTP/3 ではすべての HTTP/3 フレームが QUIC ストリーム上で送信されるため、すべてのストリーム上のすべてのフレームがフロー制御の対象となります。

他の一方向ストリームタイプが存在するため、HTTP/3 は発生中のプッシュの数を制御するために一方向ストリームの数だけに依存しません。代わりに、HTTP/3 クライアントは MAX_PUSH_ID フレームを使用してサーバが送信するプッシュの数を制御します。

多くのフレーミング概念は QUIC 上では省略可能です。フレームはすでにストリーム上にあるため、ストリーム番号を省略できます。フレームは多重化を妨げないため（QUIC の多重化はこの層の下で行われる）、可変最大長パケットのサポートを取り除けます。ストリーム終了は QUIC によって処理されるため、END_STREAM フラグは不要です。これにより一般的なフレームレイアウトから Flags フィールドを削除できます。

フレームペイロードは主に [HTTP/2] から取られています。ただし、QUIC はフロー制御等多くの機能を含み、これらは HTTP/3 で再実装されていません。その結果、HTTP/2 のいくつかのフレームタイプは HTTP/3 では不要となっています。HTTP/2 で定義されたフレームがもはや使われない場合、そのフレーム ID は互換性を高めるために予約されています。しかし、両方に出現するフレームタイプでも意味論は必ずしも同一ではありません。

多くの違いは、HTTP/2 がすべてのストリームに跨るフレーム間の絶対的な順序付けを提供するのに対し、QUIC は各ストリームごとにのみその保証を提供する事実に起因します。そのため、あるフレームタイプが異なるストリームからのフレームが送信順に受信されるという仮定を行っている場合、HTTP/3 ではこれが崩れます。

以下に機能適応のいくつかの例と、HTTP/2 の拡張を HTTP/3 に変換する拡張フレーム実装者への一般的な指針を示します。

HTTP/2 との重要な相違点の一つは、設定が control stream の最初のフレームとして一度だけ送信され、それ以降は変更できないことです。これにより変更の同期に関する多くのコーナーケースが排除されます。

HTTP/2 が SETTINGS フレームで指定するいくつかのトランスポートレベルのオプションは、HTTP/3 では QUIC トランスポートパラメータによって置き換えられます。HTTP/3 に残される HTTP レベルの設定は HTTP/2 と同じ値を持ちます。置き換えられた設定は予約され、その受信はエラーです。保持および予約された値の議論については Section 7.2.4.1 を参照してください。

SETTINGS_HEADER_TABLE_SIZE (0x01):

詳細は [QPACK] を参照してください。

SETTINGS_ENABLE_PUSH (0x02):

これは MAX_PUSH_ID フレームに置き換えられ、サーバプッシュに対するより詳細な制御を提供します。HTTP/3 の SETTINGS フレームで識別子 0x02 の設定（SETTINGS_ENABLE_PUSH に対応）を指定することはエラーです。

SETTINGS_MAX_CONCURRENT_STREAMS (0x03):

最大オープンストリームは QUIC がフロー制御ロジックの一部として制御します。HTTP/3 の SETTINGS フレームで識別子 0x03 の設定（SETTINGS_MAX_CONCURRENT_STREAMS に対応）を指定することはエラーです。

SETTINGS_INITIAL_WINDOW_SIZE (0x04):

QUIC は初期トランスポートハンドシェイクでストリームおよび接続フロー制御ウィンドウサイズの両方を指定する必要があります。HTTP/3 の SETTINGS フレームで識別子 0x04（SETTINGS_INITIAL_WINDOW_SIZE に対応）を指定することはエラーです。

SETTINGS_MAX_FRAME_SIZE (0x05):

この設定は HTTP/3 に対応するものがありません。HTTP/3 の SETTINGS フレームで識別子 0x05（SETTINGS_MAX_FRAME_SIZE に対応）を指定することはエラーです。

SETTINGS_MAX_HEADER_LIST_SIZE (0x06):

この設定識別子は SETTINGS_MAX_FIELD_SECTION_SIZE と改名されました。

HTTP/3 では設定値は可変長整数（6, 14, 30, または 62 ビット）であり、HTTP/2 の固定長 32 ビットフィールドとは異なります。これにより多くの場合エンコーディングが短くなりますが、全 32 ビット空間を使用する設定では長くなることもあります。HTTP/2 から移植された設定は、より効率的なエンコーディングのために値を 30 ビットに限定するか、30 ビットを超える必要がある場合は 62 ビット空間を利用するよう再定義することができます。

設定は HTTP/2 と HTTP/3 で別々に定義される必要があります。[HTTP/2] で定義された設定の ID は簡潔さのために予約されています。HTTP/3 の設定識別子空間は大幅に大きい（62 ビット対 16 ビット）ため、多くの HTTP/3 設定には対応する HTTP/2 のコードポイントが存在しません。Section 11.2.2 を参照してください。

QUIC ストリームは順序外に到着する可能性があるため、ピアの設定到着を待って他ストリームに応答することは避けるべきです。Section 7.2.4.2 を参照してください。

QUIC には HTTP/2 が提供する「ストリーム」および「接続」エラーの概念が存在します。しかし、HTTP/2 と HTTP/3 の違いにより、エラーコードは直接移植できません。

NO_ERROR (0x00):

H3_NO_ERROR （Section 8.1）。

PROTOCOL_ERROR (0x01):

これは、より具体的なエラーコードが定義されている場合を除き、H3_GENERAL_PROTOCOL_ERROR にマップされます。具体例には H3_FRAME_UNEXPECTED、H3_MESSAGE_ERROR、および H3_CLOSED_CRITICAL_STREAM（Section 8.1 に定義）などがあります。

INTERNAL_ERROR (0x02):

H3_INTERNAL_ERROR（Section 8.1）。

FLOW_CONTROL_ERROR (0x03):

該当しません。QUIC がフロー制御を処理するためです。

SETTINGS_TIMEOUT (0x04):

該当しません。SETTINGS の確認応答は定義されていません。

STREAM_CLOSED (0x05):

該当しません。QUIC がストリーム管理を処理するためです。

FRAME_SIZE_ERROR (0x06):

H3_FRAME_ERROR（Section 8.1 に定義）。

REFUSED_STREAM (0x07):

H3_REQUEST_REJECTED（Section 8.1）はリクエストが処理されなかったことを示すために使用されます。それ以外では QUIC がストリーム管理を処理するため該当しません。

CANCEL (0x08):

H3_REQUEST_CANCELLED（Section 8.1）。

COMPRESSION_ERROR (0x09):

複数のエラーコードが [QPACK] に定義されています。

CONNECT_ERROR (0x0a):

H3_CONNECT_ERROR（Section 8.1）。

ENHANCE_YOUR_CALM (0x0b):

H3_EXCESSIVE_LOAD（Section 8.1）。

INADEQUATE_SECURITY (0x0c):

該当しません。QUIC はすべての接続に十分なセキュリティを提供すると想定されています。

HTTP_1_1_REQUIRED (0x0d):

H3_VERSION_FALLBACK（Section 8.1）。

エラーコードは HTTP/2 と HTTP/3 で別々に定義する必要があります。Section 11.2.3 を参照してください。