[要約] RFC 9114は、HTTP/3の仕様を定義する文書であり、HTTPプロトコルの第3版を記述しています。このバージョンの主な目的は、パフォーマンスの向上、特にウェブページのロード時間の短縮を実現することにあります。HTTP/3は、QUICトランスポートプロトコルを使用して、従来のTCPに代わるものとして設計されており、接続の確立時間の短縮、パケットロスへのより効果的な対応、マルチプレックス化の改善を特徴としています。関連するRFCには、QUICを定義するRFC 9000などがあります。HTTP/3は、特に遅延が敏感なアプリケーションや、パフォーマンスを最大限に引き出したいウェブサービスで利用されます。
Internet Engineering Task Force (IETF) M. Bishop, Ed.
Request for Comments: 9114 Akamai
Category: Standards Track June 2022
ISSN: 2070-1721
HTTP/3
HTTP/3
Abstract
概要
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
QUICトランスポートプロトコルには、ストリームマルチプレックス、ストリームごとのフロー制御、低遅延接続確立など、HTTPの輸送で望ましいいくつかの機能があります。このドキュメントでは、QUICに対するHTTPセマンティクスのマッピングについて説明します。また、このドキュメントは、QUICで包含されるHTTP/2機能を識別し、HTTP/2拡張機能をHTTP/3に移植する方法について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9114.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9114で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Prior Versions of HTTP
1.2. Delegation to QUIC
2. HTTP/3 Protocol Overview
2.1. Document Organization
2.2. Conventions and Terminology
3. Connection Setup and Management
3.1. Discovering an HTTP/3 Endpoint
3.1.1. HTTP Alternative Services
3.1.2. Other Schemes
3.2. Connection Establishment
3.3. Connection Reuse
4. Expressing HTTP Semantics in HTTP/3
4.1. HTTP Message Framing
4.1.1. Request Cancellation and Rejection
4.1.2. Malformed Requests and Responses
4.2. HTTP Fields
4.2.1. Field Compression
4.2.2. Header Size Constraints
4.3. HTTP Control Data
4.3.1. Request Pseudo-Header Fields
4.3.2. Response Pseudo-Header Fields
4.4. The CONNECT Method
4.5. HTTP Upgrade
4.6. Server Push
5. Connection Closure
5.1. Idle Connections
5.2. Connection Shutdown
5.3. Immediate Application Closure
5.4. Transport Closure
6. Stream Mapping and Usage
6.1. Bidirectional Streams
6.2. Unidirectional Streams
6.2.1. Control Streams
6.2.2. Push Streams
6.2.3. Reserved Stream Types
7. HTTP Framing Layer
7.1. Frame Layout
7.2. Frame Definitions
7.2.1. DATA
7.2.2. HEADERS
7.2.3. CANCEL_PUSH
7.2.4. SETTINGS
7.2.5. PUSH_PROMISE
7.2.6. GOAWAY
7.2.7. MAX_PUSH_ID
7.2.8. Reserved Frame Types
8. Error Handling
8.1. HTTP/3 Error Codes
9. Extensions to HTTP/3
10. Security Considerations
10.1. Server Authority
10.2. Cross-Protocol Attacks
10.3. Intermediary-Encapsulation Attacks
10.4. Cacheability of Pushed Responses
10.5. Denial-of-Service Considerations
10.5.1. Limits on Field Section Size
10.5.2. CONNECT Issues
10.6. Use of Compression
10.7. Padding and Traffic Analysis
10.8. Frame Parsing
10.9. Early Data
10.10. Migration
10.11. Privacy Considerations
11. IANA Considerations
11.1. Registration of HTTP/3 Identification String
11.2. New Registries
11.2.1. Frame Types
11.2.2. Settings Parameters
11.2.3. Error Codes
11.2.4. Stream Types
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Considerations for Transitioning from HTTP/2
A.1. Streams
A.2. HTTP Frame Types
A.2.1. Prioritization Differences
A.2.2. Field Compression Differences
A.2.3. Flow-Control Differences
A.2.4. Guidance for New Frame Type Definitions
A.2.5. Comparison of HTTP/2 and HTTP/3 Frame Types
A.3. HTTP/2 SETTINGS Parameters
A.4. HTTP/2 Error Codes
A.4.1. Mapping between HTTP/2 and HTTP/3 Errors
Acknowledgments
Index
Author's Address
HTTP semantics ([HTTP]) are used for a broad range of services on the Internet. These semantics have most commonly been used with HTTP/1.1 and HTTP/2. HTTP/1.1 has been used over a variety of transport and session layers, while HTTP/2 has been used primarily with TLS over TCP. HTTP/3 supports the same semantics over a new transport protocol: QUIC.
HTTPセマンティクス（[http]）は、インターネット上の幅広いサービスに使用されます。これらのセマンティクスは、HTTP/1.1およびHTTP/2で最も一般的に使用されています。HTTP/1.1は、さまざまな輸送層とセッション層で使用されていますが、HTTP/2は主にTCPを介したTLSで使用されています。HTTP/3は、新しいトランスポートプロトコルで同じセマンティクスをサポートしています：QUIC。
HTTP/1.1 ([HTTP/1.1]) uses whitespace-delimited text fields to convey HTTP messages. While these exchanges are human readable, using whitespace for message formatting leads to parsing complexity and excessive tolerance of variant behavior.
HTTP/1.1（[http/1.1]）は、Whitespaceが削除されたテキストフィールドを使用して、HTTPメッセージを伝達します。これらの交換は人間が読みやすいですが、メッセージのフォーマットにWhitespaceを使用して、複雑さと変異行動の過度の耐性につながります。
Because HTTP/1.1 does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel. However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections.
HTTP/1.1には多重化層が含まれていないため、複数のTCP接続が並行してリクエストをサービスするために使用されることがよくあります。ただし、TCPは複数の接続間で混雑制御を共有していないため、混雑制御とネットワーク効率に悪影響を及ぼします。
HTTP/2 ([HTTP/2]) introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer. However, because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet.
HTTP/2（[HTTP/2]）は、輸送層を変更せずにレイテンシを改善するために、バイナリフレーミングと多重化層を導入しました。ただし、HTTP/2の多重化の並列性はTCPの損失回復メカニズムには見えないため、失われたパケットまたは再注文パケットにより、すべてのアクティブなトランザクションが失われたパケットによって直接影響を受けたかどうかに関係なく、失速を経験します。
The QUIC transport protocol incorporates stream multiplexing and per-stream flow control, similar to that provided by the HTTP/2 framing layer. By providing reliability at the stream level and congestion control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping. QUIC also incorporates TLS 1.3 ([TLS]) at the transport layer, offering comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open ([TFO]).
QUICトランスポートプロトコルには、HTTP/2フレーミング層によって提供されるものと同様に、ストリームマルチプレックスとストリームごとのフロー制御が組み込まれています。QUICは、接続全体にわたってストリームレベルで信頼性と輻輳制御を提供することにより、TCPマッピングと比較してHTTPのパフォーマンスを改善する機能を備えています。また、QUICにはTLS 1.3（[TLS]）が輸送層に組み込まれており、TCPを介したTLSの実行に同等の機密性と整合性を提供し、TCP Fast Open（[TFO]）の接続セットアップレイテンシが改善されています。
This document defines HTTP/3: a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2. HTTP/3 relies on QUIC to provide confidentiality and integrity protection of data; peer authentication; and reliable, in-order, per-stream delivery. While delegating stream lifetime and flow-control issues to QUIC, a binary framing similar to the HTTP/2 framing is used on each stream. Some HTTP/2 features are subsumed by QUIC, while other features are implemented atop QUIC.
このドキュメントでは、HTTP/3：QUIC輸送プロトコル上のHTTPセマンティクスのマッピングを定義し、HTTP/2の設計に大きく描かれています。HTTP/3は、データの機密性と整合性保護を提供するためにQUICに依存しています。ピア認証;信頼性の高い、注文中の、ストリームあたりの配達。Stream LifetimeおよびFlow-Controlの問題をQUICに委任する一方で、HTTP/2フレーミングと同様のバイナリフレーミングが各ストリームで使用されます。一部のHTTP/2機能はQUICで包含されますが、他の機能はQUICで実装されています。
QUIC is described in [QUIC-TRANSPORT]. For a full description of HTTP/2, see [HTTP/2].
QUICは[Quic-Transport]で説明されています。HTTP/2の完全な説明については、[http/2]を参照してください。
HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol and an internal framing layer similar to HTTP/2.
HTTP/3は、QUICトランスポートプロトコルとHTTP/2と同様の内部フレーミング層を使用して、HTTPセマンティクスのトランスポートを提供します。
Once a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection. QUIC provides protocol negotiation, stream-based multiplexing, and flow control. Discovery of an HTTP/3 endpoint is described in Section 3.1.
クライアントは、特定のエンドポイントにHTTP/3サーバーが存在することをクライアントに知ると、QUIC接続が開きます。QUICは、プロトコル交渉、ストリームベースの多重化、フロー制御を提供します。HTTP/3エンドポイントの発見については、セクション3.1で説明します。
Within each stream, the basic unit of HTTP/3 communication is a frame (Section 7.2). Each frame type serves a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses (Section 4.1). Frames that apply to the entire connection are conveyed on a dedicated control stream.
各ストリーム内で、HTTP/3通信の基本単位はフレームです（セクション7.2）。各フレームタイプは異なる目的を果たします。たとえば、ヘッダーとデータフレームは、HTTP要求と応答の基礎を形成します（セクション4.1）。接続全体に適用されるフレームは、専用のコントロールストリームで伝えられます。
Multiplexing of requests is performed using the QUIC stream abstraction, which is described in Section 2 of [QUIC-TRANSPORT]. Each request-response pair consumes a single QUIC stream. Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams.
リクエストの多重化は、[Quic-Transport]のセクション2で説明されているQUICストリーム抽象化を使用して実行されます。各リクエスト応答ペアは、単一のQUICストリームを消費します。ストリームは互いに独立しているため、パケットの損失をブロックまたは苦しむ1つのストリームは、他のストリームの進捗を防ぎません。
Server push is an interaction mode introduced in HTTP/2 ([HTTP/2]) that permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. Several HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, MAX_PUSH_ID, and CANCEL_PUSH.
サーバープッシュは、HTTP/2（[http/2]）で導入されたインタラクションモードで、サーバーは、指定された要求を行うクライアントを見越してクライアントにリクエスト応答交換をプッシュすることができます。これにより、潜在的なレイテンシゲインに対してネットワークの使用がオフになります。push_promise、max_push_id、cancel_pushなど、サーバープッシュの管理には、いくつかのHTTP/3フレームが使用されます。
As in HTTP/2, request and response fields are compressed for transmission. Because HPACK ([HPACK]) relies on in-order transmission of compressed field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses separate unidirectional streams to modify and track field table state, while encoded field sections refer to the state of the table without modifying it.
HTTP/2と同様に、リクエストフィールドと応答フィールドは伝送のために圧縮されます。HPACK（[hpack]）は圧縮フィールドセクションのインターフェンス伝送（quicによって提供されていない保証）に依存しているため、HTTP/3はHPACKをQPACK（[QPACK]）に置き換えます。QPACKは個別の単方向ストリームを使用してフィールドテーブルの状態を変更および追跡しますが、エンコードされたフィールドセクションは、テーブルの状態を変更せずに参照します。
The following sections provide a detailed overview of the lifecycle of an HTTP/3 connection:
次のセクションでは、HTTP/3接続のライフサイクルの詳細な概要を示します。
* "Connection Setup and Management" (Section 3) covers how an HTTP/3 endpoint is discovered and an HTTP/3 connection is established.
* 「接続のセットアップと管理」（セクション3）は、HTTP/3エンドポイントがどのように発見され、HTTP/3接続が確立されるかをカバーしています。
* "Expressing HTTP Semantics in HTTP/3" (Section 4) describes how HTTP semantics are expressed using frames.
* 「HTTP/3でHTTPセマンティクスの表現」（セクション4）では、HTTPセマンティクスがフレームを使用してどのように表現されるかについて説明します。
* "Connection Closure" (Section 5) describes how HTTP/3 connections are terminated, either gracefully or abruptly.
* 「接続閉鎖」（セクション5）では、HTTP/3接続が優雅にまたは突然どのように終了するかについて説明します。
The details of the wire protocol and interactions with the transport are described in subsequent sections:
ワイヤプロトコルの詳細と輸送との相互作用は、以降のセクションで説明されています。
* "Stream Mapping and Usage" (Section 6) describes the way QUIC streams are used.
* 「ストリームマッピングと使用法」（セクション6）は、QUICストリームの使用方法について説明しています。
* "HTTP Framing Layer" (Section 7) describes the frames used on most streams.
* 「HTTPフレーミングレイヤー」（セクション7）は、ほとんどのストリームで使用されるフレームについて説明しています。
* "Error Handling" (Section 8) describes how error conditions are handled and expressed, either on a particular stream or for the connection as a whole.
* 「エラー処理」（セクション8）では、特定のストリームまたは接続全体で、エラー条件がどのように処理および表現されるかについて説明します。
Additional resources are provided in the final sections:
追加のリソースが最終セクションに提供されています。
* "Extensions to HTTP/3" (Section 9) describes how new capabilities can be added in future documents.
* 「HTTP/3への拡張」（セクション9）では、将来のドキュメントで新しい機能を追加する方法について説明します。
* A more detailed comparison between HTTP/2 and HTTP/3 can be found in Appendix A.
* HTTP/2とHTTP/3のより詳細な比較は、付録Aにあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the variable-length integer encoding from [QUIC-TRANSPORT].
このドキュメントでは、[Quic-Transport]からの可変長整数エンコードを使用しています。
The following terms are used:
次の用語が使用されます。
abort: An abrupt termination of a connection or stream, possibly due to an error condition.
中止：おそらくエラー状態による接続またはストリームの急激な終了。
client: The endpoint that initiates an HTTP/3 connection. Clients send HTTP requests and receive HTTP responses.
クライアント：HTTP/3接続を開始するエンドポイント。クライアントはHTTPリクエストを送信し、HTTP応答を受け取ります。
connection: A transport-layer connection between two endpoints using QUIC as the transport protocol.
接続：輸送プロトコルとしてQUICを使用した2つのエンドポイント間の輸送層接続。
connection error: An error that affects the entire HTTP/3 connection.
接続エラー：HTTP/3接続全体に影響するエラー。
endpoint: Either the client or server of the connection.
エンドポイント：接続のクライアントまたはサーバーのいずれか。
frame: The smallest unit of communication on a stream in HTTP/3, consisting of a header and a variable-length sequence of bytes structured according to the frame type.
フレーム：HTTP/3のストリーム上の通信の最小単位。ヘッダーと、フレームタイプに従って構成されたバイトの可変長さのシーケンスで構成されています。
Protocol elements called "frames" exist in both this document and [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, the frame name will be prefaced with "QUIC". For example, "QUIC CONNECTION_CLOSE frames". References without this preface refer to frames defined in Section 7.2.
「フレーム」と呼ばれるプロトコル要素は、このドキュメントと[QUIC-ransport]の両方に存在します。[Quic-Transport]のフレームが参照される場合、フレーム名に「Quic」が付いています。たとえば、「quic connection_closeフレーム」。この序文のない参照は、セクション7.2で定義されているフレームを参照してください。
HTTP/3 connection: A QUIC connection where the negotiated application protocol is HTTP/3.
HTTP/3接続：ネゴシエートされたアプリケーションプロトコルがHTTP/3であるQUIC接続。
peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion.
ピア：エンドポイント。特定のエンドポイントについて議論するとき、「ピア」とは、議論の主要な主題にremote延するエンドポイントを指します。
receiver: An endpoint that is receiving frames.
受信機：フレームを受信しているエンドポイント。
sender: An endpoint that is transmitting frames.
送信者：フレームを送信しているエンドポイント。
server: The endpoint that accepts an HTTP/3 connection. Servers receive HTTP requests and send HTTP responses.
サーバー：HTTP/3接続を受け入れるエンドポイント。サーバーはHTTPリクエストを受信し、HTTP応答を送信します。
stream: A bidirectional or unidirectional bytestream provided by the QUIC transport. All streams within an HTTP/3 connection can be considered "HTTP/3 streams", but multiple stream types are defined within HTTP/3.
ストリーム：QUIC輸送によって提供される双方向または単方向のバイテストリーム。HTTP/3接続内のすべてのストリームは「HTTP/3ストリーム」と見なすことができますが、複数のストリームタイプはHTTP/3内で定義されています。
stream error: An application-level error on the individual stream.
ストリームエラー：個々のストリームのアプリケーションレベルのエラー。
The term "content" is defined in Section 6.4 of [HTTP].
「コンテンツ」という用語は、[HTTP]のセクション6.4で定義されています。
Finally, the terms "resource", "message", "user agent", "origin server", "gateway", "intermediary", "proxy", and "tunnel" are defined in Section 3 of [HTTP].
最後に、「リソース」、「メッセージ」、「ユーザーエージェント」、「オリジンサーバー」、「ゲートウェイ」、「仲介者」、「プロキシ」、および「トンネル」という用語は、[HTTP]のセクション3で定義されています。
Packet diagrams in this document use the format defined in Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of fields.
このドキュメントのパケット図は、[Quic-Transport]のセクション1.3で定義されている形式を使用して、フィールドの順序とサイズを示します。
HTTP relies on the notion of an authoritative response: a response that has been determined to be the most appropriate response for that request given the state of the target resource at the time of response message origination by (or at the direction of) the origin server identified within the target URI. Locating an authoritative server for an HTTP URI is discussed in Section 4.3 of [HTTP].
HTTPは、権威ある応答の概念に依存しています。応答メッセージの状態を考慮して、ターゲットリソースの状態を考慮して、その要求に対して最も適切な応答であると判断された応答は、Origin Serverによる（または方向の方向）ターゲットURI内で識別されます。HTTP URIの権威あるサーバーの検索については、[HTTP]のセクション4.3で説明します。
The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URI. Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of [HTTP]. If the certificate cannot be verified with respect to the URI's origin server, the client MUST NOT consider the server authoritative for that origin.
「HTTPS」スキームは、クライアントがURIの権限コンポーネントによって特定されたホストに対して信頼できると考える証明書の所持と、当局を関連付けます。TLSハンドシェイクでサーバー証明書を受信すると、クライアントは、[HTTP]のセクション4.3.4で説明されているプロセスを使用して、証明書がURIのOriginサーバーの許容可能な一致であることを確認する必要があります。URIのOrigin Serverに関して証明書を検証できない場合、クライアントはその原点についてサーバーを信頼できると考慮してはなりません。
A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.
クライアントは、ホスト識別子をIPアドレスに解決し、指定されたポート（上記のサーバー証明書の検証を含む）でそのアドレスへのQUIC接続を確立し、送信することにより、「HTTPS」URIを持つリソースへのアクセスを試みることができます。http/3は、その保護された接続を介してサーバーにuriをターゲットとするメッセージを要求します。HTTP/3を選択するために他のメカニズムを使用しない限り、TLSハンドシェイク中のアプリケーション層プロトコル交渉（ALPN; [RFC7301]を参照）拡張でトークン「H3」が使用されます。
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
接続の問題（UDPなどのブロックなど）は、QUIC接続の確立に失敗する可能性があります。この場合、クライアントはTCPベースのバージョンのHTTPを使用しようとする必要があります。
Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement always includes an explicit port, and URIs contain either an explicit port or a default port associated with the scheme.
サーバーは、任意のUDPポートでHTTP/3を提供できます。代替サービス広告には常に明示的なポートが含まれ、URIには明示的なポートまたはスキームに関連付けられたデフォルトポートが含まれています。
An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.
HTTPオリジンは、「H3」ALPNトークンを使用して、ALT-SVC HTTP応答ヘッダーフィールドまたはHTTP/2 ALTSVCフレーム（[AltSVC]）を介して、同等のHTTP/3エンドポイントの可用性を宣伝できます。
For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the following header field:
たとえば、OriginはHTTP応答で、次のヘッダーフィールドを含めることにより、同じホスト名でHTTP/3がUDPポート50781で利用可能であることを示しています。
Alt-Svc: h3=":50781"
On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.
HTTP/3のサポートを示すALT-SVCレコードを受信すると、クライアントは、指定されたホストとポートへのQUIC接続を確立しようとする場合があります。この接続が成功した場合、クライアントはこのドキュメントで説明されているマッピングを使用してHTTP要求を送信できます。
Although HTTP is independent of the transport protocol, the "http" scheme associates authority with the ability to receive TCP connections on the indicated port of whatever host is identified within the authority component. Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the authoritative server for a resource identified by an "http" URI. However, protocol extensions such as [ALTSVC] permit the authoritative server to identify other services that are also authoritative and that might be reachable over HTTP/3.
HTTPはトランスポートプロトコルとは独立していますが、「HTTP」スキームは、当局が当局コンポーネント内で識別されるホストの指定されたポートでTCP接続を受信する能力と関連付けます。HTTP/3はTCPを使用していないため、HTTP/3は、「HTTP」URIによって識別されたリソースの権威あるサーバーへの直接アクセスに使用できません。ただし、[altsvc]などのプロトコル拡張は、権威あるサーバーが権威ある他のサービスを特定し、HTTP/3で到達できる可能性があります。
Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. For origins whose scheme is "http", an experimental method to accomplish this is described in [RFC8164]. Other mechanisms might be defined for various schemes in the future.
スキームが「https」ではないオリジンを要求する前に、クライアントはサーバーがそのスキームを提供する意思があることを確認する必要があります。スキームが「http」である起源については、これを達成するための実験的方法は[RFC8164]で説明されています。他のメカニズムは、将来のさまざまなスキームに対して定義される可能性があります。
HTTP/3 relies on QUIC version 1 as the underlying transport. The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications.
HTTP/3は、基礎となる輸送としてQUICバージョン1に依存しています。HTTP/3を使用した他のQUIC輸送バージョンの使用は、将来の仕様によって定義される場合があります。
QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol. HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake. If the server is identified by a domain name ([DNS-TERMS]), clients MUST send the Server Name Indication (SNI; [RFC6066]) TLS extension unless an alternative mechanism to indicate the target host is used.
QUICバージョン1は、TLSバージョン1.3以上のハンドシェイクプロトコルを使用しています。HTTP/3クライアントは、TLSハンドシェイク中にサーバーにターゲットホストを示すメカニズムをサポートする必要があります。サーバーがドメイン名（[dns-terms]）によって識別された場合、クライアントはターゲットホストを示すための代替メカニズムが使用されない限り、サーバー名表示（SNI; [RFC6066]）TLS拡張を送信する必要があります。
QUIC connections are established as described in [QUIC-TRANSPORT]. During connection establishment, HTTP/3 support is indicated by selecting the ALPN token "h3" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake.
[Quic-Transport]で説明されているように、QUIC接続が確立されます。接続の確立中、HTTP/3のサポートは、TLSハンドシェイクでALPNトークン「H3」を選択することにより示されます。他のアプリケーション層プロトコルのサポートは、同じ握手で提供される場合があります。
While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, settings specific to HTTP/3 are conveyed in the SETTINGS frame. After the QUIC connection is established, a SETTINGS frame MUST be sent by each endpoint as the initial frame of their respective HTTP control stream.
コアQUICプロトコルに関連する接続レベルのオプションは、最初の暗号ハンドシェイクに設定されていますが、HTTP/3に固有の設定は設定フレームで伝達されます。QUIC接続が確立された後、それぞれのHTTP制御ストリームの初期フレームとして、各エンドポイントによって設定フレームを送信する必要があります。
HTTP/3 connections are persistent across multiple requests. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection.
HTTP/3接続は、複数の要求にわたって永続的です。最高のパフォーマンスのために、クライアントは、ユーザーが特定のWebページから離れてナビゲートするとき、またはサーバーが接続を閉じるまで（たとえば、ユーザーがナビゲートするとき）、サーバーとのさらなる通信が必要ないと判断されるまで接続を閉じないことが期待されます。
Once a connection to a server endpoint exists, this connection MAY be reused for requests with multiple different URI authority components. To use an existing connection for a new origin, clients MUST validate the certificate presented by the server for the new origin server using the process described in Section 4.3.4 of [HTTP]. This implies that clients will need to retain the server certificate and any additional information needed to verify that certificate; clients that do not do so will be unable to reuse the connection for additional origins.
サーバーエンドポイントへの接続が存在すると、この接続は、複数の異なるURI機関コンポーネントを使用した要求に対して再利用される場合があります。新しいオリジンに既存の接続を使用するには、クライアントは[HTTP]のセクション4.3.4で説明されているプロセスを使用して、新しいオリジンサーバーにサーバーが提示した証明書を検証する必要があります。これは、クライアントがサーバー証明書とその証明書を確認するために必要な追加情報を保持する必要があることを意味します。そうしないクライアントは、追加の起源の接続を再利用することができません。
If the certificate is not acceptable with regard to the new origin for any reason, the connection MUST NOT be reused and a new connection SHOULD be established for the new origin. If the reason the certificate cannot be verified might apply to other origins already associated with the connection, the client SHOULD revalidate the server certificate for those origins. For instance, if validation of a certificate fails because the certificate has expired or been revoked, this might be used to invalidate all other origins for which that certificate was used to establish authority.
何らかの理由で新しい起源に関して証明書が受け入れられない場合、接続を再利用する必要はなく、新しい起源のために新しい接続を確立する必要があります。証明書を確認できない理由が、接続にすでに関連付けられている他の起源に適用される可能性がある場合、クライアントはそれらの起源のサーバー証明書を再確認する必要があります。たとえば、証明書の検証が証明書の有効期限が切れたり取り消されたために失敗した場合、これを使用して、その証明書が権限を確立するために使用された他のすべての起源を無効にするために使用される可能性があります。
Clients SHOULD NOT open more than one HTTP/3 connection to a given IP address and UDP port, where the IP address and port might be derived from a URI, a selected alternative service ([ALTSVC]), a configured proxy, or name resolution of any of these. A client MAY open multiple HTTP/3 connections to the same IP address and UDP port using different transport or TLS configurations but SHOULD avoid creating multiple connections with the same configuration.
クライアントは、特定のIPアドレスとUDPポートへのHTTP/3接続を1つ以上開けてはいけません。IPアドレスとポートは、URI、選択された代替サービス（[AltSVC]）、構成されたプロキシ、または名前解決に由来する場合があります。これらのいずれか。クライアントは、異なるトランスポートまたはTLS構成を使用して、同じIPアドレスとUDPポートへの複数のHTTP/3接続を開くことができますが、同じ構成で複数の接続を作成しないようにする必要があります。
Servers are encouraged to maintain open HTTP/3 connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the HTTP/3 connection, the terminating endpoint SHOULD first send a GOAWAY frame (Section 5.2) so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.
サーバーは、可能な限り開いたHTTP/3接続を維持することをお勧めしますが、必要に応じてアイドル接続を終了することが許可されています。いずれかのエンドポイントがHTTP/3接続を閉じることを選択すると、終了エンドポイントは最初にgoawayフレーム（セクション5.2）を送信して、両方のエンドポイントが以前に送信されたフレームが処理されたかどうかを確実に判断し、必要な残りのタスクを優雅に完了または終了できるようにする必要があります。
A server that does not wish clients to reuse HTTP/3 connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request; see Section 7.4 of [HTTP].
クライアントが特定のオリジンのHTTP/3接続を再利用することを望まないサーバーは、要求に応じて421（誤った要求）ステータスコードを送信することにより、要求に対して権威がないことを示すことができます。[http]のセクション7.4を参照してください。
A client sends an HTTP request on a request stream, which is a client-initiated bidirectional QUIC stream; see Section 6.1. A client MUST send only a single request on a given stream. A server sends zero or more interim HTTP responses on the same stream as the request, followed by a single final HTTP response, as detailed below. See Section 15 of [HTTP] for a description of interim and final HTTP responses.
クライアントは、クライアントが開始する双方向のQUICストリームであるリクエストストリームでHTTP要求を送信します。セクション6.1を参照してください。クライアントは、特定のストリームに単一のリクエストのみを送信する必要があります。サーバーは、要求と同じストリームでゼロ以上の暫定HTTP応答を送信し、次に以下に詳述する単一の最終HTTP応答が続きます。暫定および最終的なHTTP応答の説明については、[http]のセクション15を参照してください。
Pushed responses are sent on a server-initiated unidirectional QUIC stream; see Section 6.2.2. A server sends zero or more interim HTTP responses, followed by a single final HTTP response, in the same manner as a standard response. Push is described in more detail in Section 4.6.
プッシュされた応答は、サーバーが開始した一方向のQUICストリームで送信されます。セクション6.2.2を参照してください。サーバーはゼロ以上の暫定HTTP応答を送信し、その後、標準応答と同じ方法で単一の最終HTTP応答を送信します。プッシュについては、セクション4.6で詳しく説明します。
On a given stream, receipt of multiple requests or receipt of an additional HTTP response following a final HTTP response MUST be treated as malformed.
特定のストリームでは、最終的なHTTP応答に続いて複数のリクエストの受信または追加のHTTP応答を受信することは、奇形として扱う必要があります。
An HTTP message (request or response) consists of:
HTTPメッセージ（リクエストまたは応答）は次のとおりです。
1. the header section, including message control data, sent as a single HEADERS frame,
1. メッセージ制御データを含むヘッダーセクションは、単一のヘッダーフレームとして送信されます。
2. optionally, the content, if present, sent as a series of DATA frames, and
2. オプションで、コンテンツは存在する場合、一連のデータフレームとして送信され、
3. optionally, the trailer section, if present, sent as a single HEADERS frame.
3. オプションで、トレーラーセクションは、存在する場合、単一のヘッダーフレームとして送信されます。
Header and trailer sections are described in Sections 6.3 and 6.5 of [HTTP]; the content is described in Section 6.4 of [HTTP].
ヘッダーとトレーラーのセクションについては、[HTTP]のセクション6.3および6.5で説明しています。コンテンツは、[HTTP]のセクション6.4で説明されています。
Receipt of an invalid sequence of frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. In particular, a DATA frame before any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame, is considered invalid. Other frame types, especially unknown frame types, might be permitted subject to their own rules; see Section 9.
フレームの無効なシーケンスの受信は、タイプh3_frame_unexpectedの接続エラーとして扱う必要があります。特に、ヘッダーフレームの前のデータフレーム、またはトレーリングヘッダーフレームの後のヘッダーまたはデータフレームは無効と見なされます。他のフレームタイプ、特に未知のフレームタイプは、独自のルールの対象となる可能性があります。セクション9を参照してください。
A server MAY send one or more PUSH_PROMISE frames before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see Section 4.6 for more details. PUSH_PROMISE frames are not permitted on push streams; a pushed response that includes PUSH_PROMISE frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
サーバーは、応答メッセージのフレームと1つまたは複数のPush_Promiseフレームを送信することができます。これらのPush_Promiseフレームは、応答の一部ではありません。詳細については、セクション4.6を参照してください。Push_Promiseフレームは、プッシュストリームでは許可されていません。push_promiseフレームを含むプッシュされた応答は、タイプh3_frame_unexpectentの接続エラーとして扱う必要があります。
Frames of unknown types (Section 9), including reserved frames (Section 7.2.8) MAY be sent on a request or push stream before, after, or interleaved with other frames described in this section.
予約されたフレーム（セクション7.2.8）を含む未知のタイプのフレーム（セクション9）は、このセクションで説明されている他のフレームとのリクエストまたはプッシュストリームで送信される場合があります。
The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic table. While these updates are not directly part of the message exchange, they must be received and processed before the message can be consumed. See Section 4.2 for more details.
ヘッダーとpush_promiseフレームは、qpackダイナミックテーブルの更新を参照する場合があります。これらの更新はメッセージ交換の直接の一部ではありませんが、メッセージを消費する前に受信および処理する必要があります。詳細については、セクション4.2を参照してください。
Transfer codings (see Section 7 of [HTTP/1.1]) are not defined for HTTP/3; the Transfer-Encoding header field MUST NOT be used.
転送コーディング（[http/1.1]のセクション7を参照）は、http/3では定義されていません。転送エンコードヘッダーフィールドを使用してはなりません。
A response MAY consist of multiple messages when and only when one or more interim responses (1xx; see Section 15.2 of [HTTP]) precede a final response to the same request. Interim responses do not contain content or trailer sections.
応答は、1つ以上の暫定応答（1xx; [http]のセクション15.2を参照）が同じリクエストに対する最終的な応答の前にの場合にのみ、複数のメッセージで構成されます。暫定応答には、コンテンツやトレーラーセクションが含まれていません。
An HTTP request/response exchange fully consumes a client-initiated bidirectional QUIC stream. After sending a request, a client MUST close the stream for sending. Unless using the CONNECT method (see Section 4.4), clients MUST NOT make stream closure dependent on receiving a response to their request. After sending a final response, the server MUST close the stream for sending. At this point, the QUIC stream is fully closed.
HTTPリクエスト/応答交換は、クライアントが開始する双方向のQUICストリームを完全に消費します。リクエストを送信した後、クライアントは送信のためにストリームを閉じる必要があります。Connectメソッドを使用しない限り（セクション4.4を参照）、クライアントはリクエストに対する応答を受信することに依存してストリームを閉じることはできません。最終的な応答を送信した後、サーバーは送信のためにストリームを閉じる必要があります。この時点で、QUICストリームは完全に閉じられています。
When a stream is closed, this indicates the end of the final HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress. If a client-initiated stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE.
ストリームが閉じたとき、これは最終的なHTTPメッセージの終了を示します。一部のメッセージは大きいまたは無制限であるため、エンドポイントは、進行するために十分なメッセージが受信されたら、部分的なHTTPメッセージの処理を開始する必要があります。クライアントが開始したストリームが完全な応答を提供するのに十分なHTTPメッセージなしで終了する場合、サーバーはエラーコードh3_request_incompleteで応答ストリームを中止する必要があります。
A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When the server does not need to receive the remainder of the request, it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream. The error code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on the request stream. Clients MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons. If the server sends a partial or complete response but does not abort reading the request, clients SHOULD continue sending the content of the request and close the stream normally.
サーバーは、送信されて受信されていないリクエストの一部に依存しない場合、クライアントがリクエスト全体を送信する前に完全な応答を送信できます。サーバーがリクエストの残りの部分を受信する必要がない場合、リクエストストリームの読み取りを中止し、完全な応答を送信し、ストリームの送信部分をきれいに閉じます。エラーコードH3_NO_ERRORは、クライアントがリクエストストリームの送信を停止するよう要求するときに使用する必要があります。クライアントは、リクエストが突然終了した結果として完全な応答を破棄してはなりませんが、クライアントは他の理由で常に裁量で回答を廃棄することができます。サーバーが部分的または完全な応答を送信するが、リクエストの読み取りを中止しない場合、クライアントはリクエストのコンテンツを送信し続け、通常のストリームを閉じる必要があります。
Once a request stream has been opened, the request MAY be cancelled by either endpoint. Clients cancel requests if the response is no longer of interest; servers cancel requests if they are unable to or choose not to respond. When possible, it is RECOMMENDED that servers send an HTTP response with an appropriate status code rather than cancelling a request it has already begun processing.
リクエストストリームが開かれると、どちらのエンドポイントによって要求がキャンセルされる場合があります。応答が関心がなくなった場合、クライアントはリクエストをキャンセルします。サーバーは、応答できない場合、または応答しないことを選択した場合にリクエストをキャンセルします。可能であれば、サーバーは、すでに処理を開始しているリクエストをキャンセルするのではなく、適切なステータスコードでHTTP応答を送信することをお勧めします。
Implementations SHOULD cancel requests by abruptly terminating any directions of a stream that are still open. To do so, an implementation resets the sending parts of streams and aborts reading on the receiving parts of streams; see Section 2.4 of [QUIC-TRANSPORT].
実装は、まだ開いているストリームの方向を突然終了することにより、リクエストをキャンセルする必要があります。そのために、実装は、ストリームの送信部品をリセットし、ストリームの受信部分で読み取りを中止します。[Quic-Transport]のセクション2.4を参照してください。
When the server cancels a request without performing any application processing, the request is considered "rejected". The server SHOULD abort its response stream with the error code H3_REQUEST_REJECTED. In this context, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. The client can treat requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later.
サーバーがアプリケーション処理を実行せずにリクエストをキャンセルすると、リクエストは「拒否された」と見なされます。サーバーは、エラーコードH3_Request_Rejedを使用して応答ストリームを中止する必要があります。この文脈では、「処理された」ということは、ストリームからの一部のデータが、結果として何らかのアクションをとった可能性のあるソフトウェアのより高い層に渡されたことを意味します。クライアントは、サーバーによって拒否された要求をまったく送信したことがないかのように扱うことができ、それにより後で再試行することができます。
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were partially or fully processed. When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED.
サーバーは、部分的または完全に処理されたリクエストに対して、H3_Request_Rejectedエラーコードを使用してはなりません。部分処理後にサーバーが応答を放棄すると、エラーコードh3_request_cancelledを使用して応答ストリームを中止する必要があります。
Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests. Upon receipt of this error code, a server MAY abruptly terminate the response using the error code H3_REQUEST_REJECTED if no processing was performed. Clients MUST NOT use the H3_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code.
クライアントは、エラーコードH3_Request_Cancelledを使用してリクエストをキャンセルする必要があります。このエラーコードを受け取ると、サーバーは、処理が実行されなかった場合にエラーコードH3_Request_Rejedを使用して応答を突然終了する場合があります。クライアントは、サーバーがこのエラーコードでリクエストストリームのクロージャーを要求した場合を除き、H3_Request_Rejectedエラーコードを使用してはなりません。
If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response. However, if a stream is cancelled after receiving a partial response, the response SHOULD NOT be used. Only idempotent actions such as GET, PUT, or DELETE can be safely retried; a client SHOULD NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are idempotent independent of the method or some means to detect that the original request was never applied. See Section 9.2.2 of [HTTP] for more details.
完全な応答を受け取った後にストリームがキャンセルされた場合、クライアントはキャンセルを無視し、応答を使用する場合があります。ただし、部分的な応答を受信した後にストリームがキャンセルされた場合、応答は使用しないでください。GET、PUT、または削除などの等身アクションのみを安全に再試行できます。クライアントは、リクエストセマンティクスがメソッドとは無関係であるか、元のリクエストが適用されなかったことを検出するための何らかの手段であることを知っている手段がない限り、非公開法でリクエストを自動的に再試行するべきではありません。詳細については、[http]のセクション9.2.2を参照してください。
A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to:
不正な要求または応答は、それ以外の場合は有効なフレームのシーケンスであるが、以下のために無効なものです。
* the presence of prohibited fields or pseudo-header fields,
* 禁止されたフィールドまたは擬似ヘッダーフィールドの存在、
* the absence of mandatory pseudo-header fields,
* 必須の擬似ヘッダーフィールドがない、
* invalid values for pseudo-header fields,
* 擬似ヘッダーフィールドの無効な値、
* pseudo-header fields after fields,
* フィールドの後の擬似ヘッダーフィールド、
* an invalid sequence of HTTP messages,
* HTTPメッセージの無効なシーケンス、
* the inclusion of uppercase field names, or
* 大文字のフィールド名を含める、または
* the inclusion of invalid characters in field names or values.
* フィールド名または値に無効な文字を含めること。
A request or response that is defined as having content when it contains a Content-Length header field (Section 8.6 of [HTTP]) is malformed if the value of the Content-Length header field does not equal the sum of the DATA frame lengths received. A response that is defined as never having content, even when a Content-Length is present, can have a non-zero Content-Length header field even though no content is included in DATA frames.
コンテンツ長ヘッダーフィールド（[http]のセクション8.6）を含むときにコンテンツを持つと定義される要求または応答は、コンテンツ長ヘッダーフィールドの値が受信したデータフレーム長の合計に等しくない場合に奇形されます。コンテンツの長さが存在する場合でも、コンテンツを持たないと定義される応答は、データフレームにはコンテンツが含まれていない場合でも、ゼロ以外のコンテンツ長ヘッダーフィールドを持つことができます。
Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. Malformed requests or responses that are detected MUST be treated as a stream error of type H3_MESSAGE_ERROR.
HTTP要求または応答を処理する仲介者（つまり、トンネルとして機能しない仲介者）は、奇形の要求または応答を転送してはなりません。検出された不正な要求または応答は、タイプh3_message_errorのストリームエラーとして扱う必要があります。
For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream. Clients MUST NOT accept a malformed response. Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities.
不正な要求の場合、サーバーは、ストリームを閉じる前またはリセットする前にエラーを示すHTTP応答を送信する場合があります。クライアントは不正な応答を受け入れてはなりません。これらの要件は、HTTPに対するいくつかのタイプの一般的な攻撃から保護することを目的としていることに注意してください。寛容であることは、これらの脆弱性に実装を公開する可能性があるため、意図的に厳格です。
HTTP messages carry metadata as a series of key-value pairs called "HTTP fields"; see Sections 6.3 and 6.5 of [HTTP]. For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/ http-fields/>. Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields.
HTTPメッセージは、「HTTPフィールド」と呼ばれる一連のキー価値ペアとしてメタデータを運びます。[http]のセクション6.3および6.5を参照してください。登録されたHTTPフィールドのリストについては、<https://www.iana.org/assignments/ http-fields/>に維持されている「ハイパーテキスト転送プロトコル（http）フィールド名レジストリ」を参照してください。HTTP/2と同様に、HTTP/3には、フィールド名、接続ヘッダーフィールド、および擬似ヘッダーフィールドでの文字の使用に関する追加の考慮事項があります。
Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of [HTTP]. Characters in field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed.
フィールド名は、ASCII文字のサブセットを含む文字列です。HTTPフィールド名と値のプロパティについては、[HTTP]のセクション5.1で詳細に説明します。フィールド名の文字は、エンコードの前に小文字に変換する必要があります。フィールド名に大文字の文字を含むリクエストまたは応答は、奇形として扱う必要があります。
HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as malformed.
HTTP/3は、接続ヘッダーフィールドを使用して接続固有のフィールドを示しません。このプロトコルでは、接続固有のメタデータは他の手段によって伝えられます。エンドポイントは、接続固有のフィールドを含むHTTP/3フィールドセクションを生成してはなりません。接続固有のフィールドを含むメッセージは、奇形として扱う必要があります。
The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain any value other than "trailers".
これの唯一の例外は、HTTP/3要求ヘッダーに存在する場合があるTEヘッダーフィールドです。そうである場合、「トレーラー」以外の値を含めてはなりません。
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST remove connection-specific header fields as discussed in Section 7.6.1 of [HTTP], or their messages will be treated by other HTTP/3 endpoints as malformed.
HTTP/1.xメッセージをHTTP/3に変換する仲介者は、[HTTP]のセクション7.6.1で説明したように接続固有のヘッダーフィールドを削除する必要があります。
[QPACK] describes a variation of HPACK that gives an encoder some control over how much head-of-line blocking can be caused by compression. This allows an encoder to balance compression efficiency with latency. HTTP/3 uses QPACK to compress header and trailer sections, including the control data present in the header section.
[QPACK]は、エンコーダーに圧縮によってヘッドオブラインブロッキングの量がどの程度引き起こされるかをある程度制御できるHPACKのバリエーションを説明しています。これにより、エンコーダーは圧縮効率とレイテンシのバランスをとることができます。HTTP/3は、QPACKを使用して、ヘッダーセクションに存在するコントロールデータを含むヘッダーセクションとトレーラーセクションを圧縮します。
To allow for better compression efficiency, the Cookie header field ([COOKIES]) MAY be split into separate field lines, each with one or more cookie-pairs, before compression. If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter of "; " (ASCII 0x3b, 0x20) before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application.
圧縮効率を向上させるために、Cookieヘッダーフィールド（[Cookie]）は、圧縮の前に、それぞれ1つ以上のCookieペアを備えた個別のフィールドラインに分割できます。減圧されたフィールドセクションに複数のCookieフィールドラインが含まれている場合、これらは ";"（ascii 0x3b、0x20）の2バイトの区切り文字を使用して単一のバイト文字列に連結する必要があります。3、HTTP/1.1接続、および汎用HTTPサーバーアプリケーションなど。
An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message. A server that receives a larger header section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code ([RFC6585]). A client can discard responses that it cannot process. The size of a field list is calculated based on the uncompressed size of fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each field.
HTTP/3実装は、個々のHTTPメッセージで受け入れるメッセージヘッダーの最大サイズに制限を課す場合があります。処理するよりも大きなヘッダーセクションを受信するサーバーは、HTTP 431（リクエストヘッダーフィールドが大きすぎる）ステータスコード（[RFC6585]）を送信できます。クライアントは、処理できない応答を破棄できます。フィールドリストのサイズは、バイトの名前と値の長さと各フィールドの32バイトのオーバーヘッドを含む、フィールドの非圧縮サイズのサイズに基づいて計算されます。
If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it. However, an HTTP message can traverse one or more intermediaries before reaching the origin server; see Section 3.7 of [HTTP]. Because this limit is applied separately by each implementation that processes the message, messages below this limit are not guaranteed to be accepted.
実装がこの制限をピアに助言することを希望する場合、settings_max_field_section_sizeパラメーターの多くのバイトとして伝えることができます。このパラメーターを受信した実装は、指定されたサイズを超えるHTTPメッセージヘッダーを送信してはなりません。ピアはおそらく処理を拒否する可能性が高いためです。ただし、HTTPメッセージは、Origin Serverに到達する前に1つ以上の仲介者を通過できます。[http]のセクション3.7を参照してください。この制限は、メッセージを処理する各実装によって個別に適用されるため、この制限以下のメッセージは受け入れられることは保証されていません。
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where the field name begins with the : character (ASCII 0x3a). These pseudo-header fields convey message control data; see Section 6.2 of [HTTP].
HTTP/2と同様に、HTTP/3は一連の擬似ヘッダーフィールドを採用しています。ここでは、フィールド名は次のようなもので始まります（ASCII 0x3a）。これらの擬似ヘッダーフィールドは、メッセージ制御データを伝えます。[http]のセクション6.2を参照してください。
Pseudo-header fields are not HTTP fields. Endpoints MUST NOT generate pseudo-header fields other than those defined in this document. However, an extension could negotiate a modification of this restriction; see Section 9.
擬似ヘッダーフィールドはHTTPフィールドではありません。エンドポイントは、このドキュメントで定義されているもの以外の擬似ヘッダーフィールドを生成してはなりません。ただし、拡張機能はこの制限の変更を交渉する可能性があります。セクション9を参照してください。
Pseudo-header fields are only valid in the context in which they are defined. Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST NOT appear in trailer sections. Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed.
擬似ヘッダーフィールドは、定義されているコンテキストでのみ有効です。リクエストに対して定義された擬似ヘッダーフィールドは、応答に表示されてはなりません。応答のために定義された擬似ヘッダーフィールドは、リクエストに表示されてはなりません。擬似ヘッダーフィールドは、トレーラーセクションに表示されてはなりません。エンドポイントは、未定義または無効な擬似ヘッダーフィールドを含む要求または応答を奇形として扱う必要があります。
All pseudo-header fields MUST appear in the header section before regular header fields. Any request or response that contains a pseudo-header field that appears in a header section after a regular header field MUST be treated as malformed.
すべての擬似ヘッダーフィールドは、通常のヘッダーフィールドの前にヘッダーセクションに表示する必要があります。通常のヘッダーフィールドの後にヘッダーセクションに表示される疑似ヘッダーフィールドを含むリクエストまたは応答は、奇形として扱わなければなりません。
The following pseudo-header fields are defined for requests:
次の擬似ヘッダーフィールドは、リクエスト用に定義されています。
":method": Contains the HTTP method (Section 9 of [HTTP])
"：method"：httpメソッド（[http]のセクション9）が含まれています
":scheme": Contains the scheme portion of the target URI (Section 3.1 of [URI]).
「：スキーム」：ターゲットURIのスキーム部分（[URI]のセクション3.1）が含まれています。
The :scheme pseudo-header is not restricted to URIs with scheme "http" and "https". A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services.
The：Scheme Pseudo-Headerは、スキーム「HTTP」と「HTTPS」を使用してURISに限定されません。プロキシまたはゲートウェイは、非HTTPスキームのリクエストを翻訳して、HTTPを使用して非HTTPサービスと対話できるようにすることができます。
See Section 3.1.2 for guidance on using a scheme other than "https".
「HTTPS」以外のスキームを使用するガイダンスについては、セクション3.1.2を参照してください。
":authority": Contains the authority portion of the target URI (Section 3.2 of [URI]). The authority MUST NOT include the deprecated userinfo subcomponent for URIs of scheme "http" or "https".
「：権限」：ターゲットURIの権限部分（[URI]のセクション3.2）が含まれています。当局には、スキーム「HTTP」または「HTTPS」のURISの非推奨ユーザーインフェサブコンポーネントを含めてはなりません。
To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in a method-specific form; see Section 7.1 of [HTTP]. Clients that generate HTTP/3 requests directly SHOULD use the :authority pseudo-header field instead of the Host header field. An intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host field if one is not present in a request by copying the value of the :authority pseudo-header field.
HTTP/1.1要求行を正確に再現できることを確認するには、メソッド固有の形式の要求ターゲットを持つHTTP/1.1要求から変換する場合、この擬似ヘッダーフィールドを省略する必要があります。[http]のセクション7.1を参照してください。HTTP/3リクエストを直接生成するクライアントは、ホストヘッダーフィールドの代わりに、authority pseudo-headerフィールドを使用する必要があります。HTTP/3要求をHTTP/1.1に変換する仲介者は、以下の値をコピーしてリクエストに存在しない場合は、ホストフィールドを作成する必要があります。
":path": Contains the path and query parts of the target URI (the "path-absolute" production and optionally a ? character (ASCII 0x3f) followed by the "query" production; see Sections 3.3 and 3.4 of [URI].
"：PATH"：ターゲットURIのパスとクエリの部分（「パスアブソルート」の生成、およびオプションでは、「クエリ」生産が続きます。[URI]のセクション3.3および3.4を参照してください。
This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of / (ASCII 0x2f). An OPTIONS request that does not include a path component includes the value * (ASCII 0x2a) for the :path pseudo-header field; see Section 7.1 of [HTTP].
この擬似ヘッダーフィールドは、「http」または「https」urisの場合は空にしてはなりません。パスコンポーネントを含まない「HTTP」または「HTTPS」URIは、 /（ASCII 0x2F）の値を含める必要があります。パスコンポーネントを含まないオプションリクエストには、以下の値 *（ASCII 0x2a）が含まれます。[http]のセクション7.1を参照してください。
All HTTP/3 requests MUST include exactly one value for the :method, :scheme, and :path pseudo-header fields, unless the request is a CONNECT request; see Section 4.4.
すべてのHTTP/3リクエストには、リクエストが接続要求でない限り、メソッド、スキーム、および：PATH PSEUDO-HEADERフィールドに正確に1つの値を含める必要があります。セクション4.4を参照してください。
If the :scheme pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an :authority pseudo-header field or a Host header field. If these fields are present, they MUST NOT be empty. If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the :authority pseudo-header or Host header fields.
スキームの擬似ヘッダーフィールドが、必須の権限コンポーネント（「HTTP」および「HTTPS」を含む）を持つスキームを識別する場合、要求には、aniversion擬似ヘッダーフィールドまたはホストヘッダーフィールドのいずれかを含める必要があります。これらのフィールドが存在する場合、それらは空であってはなりません。両方のフィールドが存在する場合、同じ値を含める必要があります。スキームに必須の権限コンポーネントがなく、要求ターゲットに提供されていない場合、要求には以下を含めてはなりません。
An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those pseudo-header fields is malformed.
必須の擬似ヘッダーフィールドを省略したり、これらの擬似ヘッダーフィールドの無効な値を含むHTTP要求は奇形です。
HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. HTTP/3 requests implicitly have a protocol version of "3.0".
HTTP/3は、HTTP/1.1要求行に含まれるバージョン識別子を運ぶ方法を定義しません。HTTP/3要求は、暗黙的に「3.0」のプロトコルバージョンを持っています。
For responses, a single ":status" pseudo-header field is defined that carries the HTTP status code; see Section 15 of [HTTP]. This pseudo-header field MUST be included in all responses; otherwise, the response is malformed (see Section 4.1.2).
応答の場合、単一の「ステータス」擬似ヘッダーフィールドが定義されています。[http]のセクション15を参照してください。この擬似ヘッダーフィールドは、すべての応答に含める必要があります。それ以外の場合、応答は奇形です（セクション4.1.2を参照）。
HTTP/3 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. HTTP/3 responses implicitly have a protocol version of "3.0".
HTTP/3は、HTTP/1.1ステータス行に含まれるバージョンまたは理由のフレーズを携帯する方法を定義しません。HTTP/3応答には、暗黙的に「3.0」のプロトコルバージョンがあります。
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target; see Section 9.3.6 of [HTTP]. It is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.
Connectメソッドは、受信者がリクエストターゲットによって識別された宛先オリジンサーバーへのトンネルを確立することを要求します。[http]のセクション9.3.6を参照してください。主にHTTPプロキシで使用され、「HTTPS」リソースとの対話を目的として、Origin ServerとTLSセッションを確立します。
In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT method is used to establish a tunnel over a single stream.
HTTP/1.xでは、Connectを使用して、HTTP接続全体をトンネルにリモートホストに変換します。HTTP/2およびHTTP/3では、Connectメソッドを使用して、単一のストリームにトンネルを確立します。
A CONNECT request MUST be constructed as follows:
接続要求は次のように作成する必要があります。
* The :method pseudo-header field is set to "CONNECT"
* The：Method Pseudo-Headerフィールドは「接続」に設定されています
* The :scheme and :path pseudo-header fields are omitted
* ：スキームと：パス疑似ヘッダーフィールドは省略されています
* The :authority pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target of CONNECT requests; see Section 7.1 of [HTTP]).
* The：Authority Pseudo-Headerフィールドには、接続するホストとポートが含まれています（Connectリクエストの要求標的の権限形式に相当します。[HTTP]のセクション7.1を参照）。
The request stream remains open at the end of the request to carry the data to be transferred. A CONNECT request that does not conform to these restrictions is malformed.
リクエストストリームは、転送されるデータを運ぶリクエストの最後に開いたままです。これらの制限に準拠していない接続要求は奇形です。
A proxy that supports CONNECT establishes a TCP connection ([RFC0793]) to the server identified in the :authority pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in Section 15.3 of [HTTP].
Connectをサポートするプロキシは、TCP接続（[RFC0793]）を確立します。この接続が正常に確立されると、プロキシは[HTTP]のセクション15.3で定義されているように、2xxシリーズステータスコードを含むヘッダーフレームをクライアントに送信します。
All DATA frames on the stream correspond to data sent or received on the TCP connection. The payload of any DATA frame sent by the client is transmitted by the proxy to the TCP server; data received from the TCP server is packaged into DATA frames by the proxy. Note that the size and number of TCP segments is not guaranteed to map predictably to the size and number of HTTP DATA or QUIC STREAM frames.
ストリーム上のすべてのデータフレームは、TCP接続で送信または受信したデータに対応しています。クライアントが送信したデータフレームのペイロードは、プロキシによってTCPサーバーに送信されます。TCPサーバーから受信したデータは、プロキシによってデータフレームにパッケージ化されます。TCPセグメントのサイズと数は、HTTPデータまたはQUICストリームフレームのサイズと数に予測可能にマッピングすることを保証されていないことに注意してください。
Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension. Receipt of any other known frame type MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Connectメソッドが完了すると、データフレームのみがストリームで送信されることが許可されます。拡張フレームは、拡張機能の定義によって特別に許可されている場合に使用できます。他の既知のフレームタイプの受信は、型h3_frame_unexpectedのタイプの接続エラーとして扱わなければなりません。
The TCP connection can be closed by either peer. When the client ends the request stream (that is, the receive stream at the proxy enters the "Data Recvd" state), the proxy will set the FIN bit on its connection to the TCP server. When the proxy receives a packet with the FIN bit set, it will close the send stream that it sends to the client. TCP connections that remain half closed in a single direction are not invalid, but are often handled poorly by servers, so clients SHOULD NOT close a stream for sending while they still expect to receive data from the target of the CONNECT.
TCP接続は、いずれかのピアで閉じることができます。クライアントがリクエストストリームを終了すると（つまり、プロキシの受信ストリームが「データRECVD」状態に入ります）、プロキシはTCPサーバーへの接続でFINビットを設定します。プロキシがFINビットセットでパケットを受信すると、クライアントに送信する送信ストリームが閉じます。1つの方向に半分閉じたままのTCP接続は無効ではありませんが、サーバーによって不十分に処理されることが多いため、クライアントは接続のターゲットからデータを受け取ることを期待している間、送信のためにストリームを閉じるべきではありません。
A TCP connection error is signaled by abruptly terminating the stream. A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of type H3_CONNECT_ERROR.
TCP接続エラーは、ストリームを突然終了させることによりシグナルです。プロキシは、TCP接続のエラーを扱います。これには、rts bit Setを使用してTCPセグメントを受信すること、タイプH3_Connect_Errorのストリームエラーとして扱います。
Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection. If the proxy detects that the client has reset the stream or aborted reading from the stream, it MUST close the TCP connection. If the stream is reset or reading is aborted by the client, a proxy SHOULD perform the same operation on the other direction in order to ensure that both directions of the stream are cancelled. In all these cases, if the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set.
それに対応して、プロキシがストリームまたはQUIC接続でエラーを検出した場合、TCP接続を閉じる必要があります。プロキシがクライアントがストリームをリセットしたり、ストリームから読み取りを中止したりすることを検出した場合、TCP接続を閉じる必要があります。クライアントによってストリームがリセットされているか、読み取りが中止されている場合、プロキシは、ストリームの両方の方向がキャンセルされるように、他の方向に同じ操作を実行する必要があります。これらすべての場合、基礎となるTCP実装が許可されている場合、プロキシはRST BIT SETでTCPセグメントを送信する必要があります。
Since CONNECT creates a tunnel to an arbitrary server, proxies that support CONNECT SHOULD restrict its use to a set of known ports or a list of safe request targets; see Section 9.3.6 of [HTTP] for more details.
Connectは任意のサーバーにトンネルを作成するため、Connectをサポートするプロキシは、その使用を一連の既知のポートまたは安全なリクエストターゲットのリストに制限する必要があります。詳細については、[http]のセクション9.3.6を参照してください。
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of [HTTP]) or the 101 (Switching Protocols) informational status code (Section 15.2.2 of [HTTP]).
HTTP/3は、HTTPアップグレードメカニズム（[HTTP]のセクション7.8）または101（スイッチングプロトコル）情報ステータスコード（[HTTP]のセクション15.2.2）をサポートしていません。
Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. HTTP/3 server push is similar to what is described in Section 8.2 of [HTTP/2], but it uses different mechanisms.
サーバープッシュは、指定された要求を作成するクライアントを見越して、サーバーがクライアントにリクエスト応答交換をプッシュできるようにするインタラクションモードです。これにより、潜在的なレイテンシゲインに対してネットワークの使用がオフになります。HTTP/3サーバーのプッシュは、[HTTP/2]のセクション8.2で説明されているものと似ていますが、さまざまなメカニズムを使用しています。
Each server push is assigned a unique push ID by the server. The push ID is used to refer to the push in various contexts throughout the lifetime of the HTTP/3 connection.
各サーバープッシュには、サーバーによって一意のプッシュIDが割り当てられます。プッシュIDは、HTTP/3接続の生涯を通じてさまざまなコンテキストでのプッシュを参照するために使用されます。
The push ID space begins at zero and ends at a maximum value set by the MAX_PUSH_ID frame. In particular, a server is not able to push until after the client sends a MAX_PUSH_ID frame. A client sends MAX_PUSH_ID frames to control the number of pushes that a server can promise. A server SHOULD use push IDs sequentially, beginning from zero. A client MUST treat receipt of a push stream as a connection error of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent or when the stream references a push ID that is greater than the maximum push ID.
プッシュIDスペースはゼロから始まり、MAX_PUSH_IDフレームによって設定された最大値で終了します。特に、クライアントがMAX_PUSH_IDフレームを送信するまでサーバーはプッシュできません。クライアントはMAX_PUSH_IDフレームを送信して、サーバーが約束できるプッシュの数を制御します。サーバーは、ゼロから始まるプッシュIDを順番に使用する必要があります。クライアントは、MAX_PUSH_IDフレームが送信されていない場合、またはストリームが最大プッシュIDよりも大きいプッシュIDを参照している場合、プッシュストリームの受信をタイプH3_ID_ERRORの接続エラーとして扱う必要があります。
The push ID is used in one or more PUSH_PROMISE frames that carry the control data and header fields of the request message. These frames are sent on the request stream that generated the push. This allows the server push to be associated with a client request. When the same push ID is promised on multiple request streams, the decompressed request field sections MUST contain the same fields in the same order, and both the name and the value in each field MUST be identical.
プッシュIDは、リクエストメッセージの制御データとヘッダーフィールドを運ぶ1つ以上のPush_Promiseフレームで使用されます。これらのフレームは、プッシュを生成したリクエストストリームで送信されます。これにより、サーバーのプッシュがクライアントリクエストに関連付けることができます。複数の要求ストリームで同じプッシュIDが約束されている場合、減圧要求フィールドセクションに同じ順序で同じフィールドを含める必要があり、各フィールドの名前と値の両方が同一でなければなりません。
The push ID is then included with the push stream that ultimately fulfills those promises. The push stream identifies the push ID of the promise that it fulfills, then contains a response to the promised request as described in Section 4.1.
プッシュIDは、最終的にそれらの約束を果たすプッシュストリームに含まれます。プッシュストリームは、それが満たす約束のプッシュIDを識別し、セクション4.1で説明したように、約束された要求への応答を含みます。
Finally, the push ID can be used in CANCEL_PUSH frames; see Section 7.2.3. Clients use this frame to indicate they do not wish to receive a promised resource. Servers use this frame to indicate they will not be fulfilling a previous promise.
最後に、プッシュIDはcancel_pushフレームで使用できます。セクション7.2.3を参照してください。クライアントはこのフレームを使用して、約束のリソースを受け取りたくないことを示します。サーバーは、このフレームを使用して、以前の約束を果たさないことを示します。
Not all requests can be pushed. A server MAY push requests that have the following properties:
すべてのリクエストをプッシュできるわけではありません。サーバーは、次のプロパティを持つリクエストをプッシュする場合があります。
* cacheable; see Section 9.2.3 of [HTTP]
* キャッシュ可能;[http]のセクション9.2.3を参照してください
* safe; see Section 9.2.1 of [HTTP]
* 安全;[http]のセクション9.2.1を参照してください
* does not include request content or a trailer section
* リクエストコンテンツやトレーラーセクションは含まれていません
The server MUST include a value in the :authority pseudo-header field for which the server is authoritative. If the client has not yet validated the connection for the origin indicated by the pushed request, it MUST perform the same verification process it would do before sending a request for that origin on the connection; see Section 3.3. If this verification fails, the client MUST NOT consider the server authoritative for that origin.
サーバーには、サーバーが権威あるauthorityの擬似ヘッダーフィールドに値を含める必要があります。クライアントがプッシュされたリクエストで示されている原点の接続をまだ検証していない場合、接続でその原点のリクエストを送信する前に同じ検証プロセスを実行する必要があります。セクション3.3を参照してください。この検証が失敗した場合、クライアントは、その起源についてサーバーを権威あると考慮してはなりません。
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of request content, or for which it does not consider the server authoritative. Any corresponding responses MUST NOT be used or cached.
クライアントは、キャッシュ不可能ではない、安全であることが知られていない、リクエストコンテンツの存在を示す、またはサーバーが権威あるとは見なさないリクエストを伝えるPush_Promiseフレームを受信したときにCancel_Pushフレームを送信する必要があります。対応する応答は、使用またはキャッシュしてはなりません。
Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the PUSH_PROMISE frame was received. The same server push can be associated with additional client requests using a PUSH_PROMISE frame with the same push ID on multiple request streams. These associations do not affect the operation of the protocol, but they MAY be considered by user agents when deciding how to use pushed resources.
各プッシュされた応答は、1つ以上のクライアントリクエストに関連付けられています。プッシュは、push_promiseフレームが受信された要求ストリームに関連付けられています。同じサーバーのプッシュは、複数のリクエストストリームで同じプッシュIDを使用して、Push_promiseフレームを使用した追加のクライアント要求に関連付けられます。これらの関連付けは、プロトコルの動作に影響しませんが、プッシュリソースの使用方法を決定する際にユーザーエージェントが考慮することができます。
Ordering of a PUSH_PROMISE frame in relation to certain parts of the response is important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS or DATA frames that reference the promised responses. This reduces the chance that a client requests a resource that will be pushed by the server.
応答の特定の部分に関連したPush_Promiseフレームの順序付けが重要です。サーバーは、約束された応答を参照するヘッダーまたはデータフレームを送信する前に、push_promiseフレームを送信する必要があります。これにより、クライアントがサーバーによってプッシュされるリソースを要求する可能性が減ります。
Due to reordering, push stream data can arrive before the corresponding PUSH_PROMISE frame. When a client receives a new push stream with an as-yet-unknown push ID, both the associated client request and the pushed request header fields are unknown. The client can buffer the stream data in expectation of the matching PUSH_PROMISE. The client can use stream flow control (Section 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may commit to the pushed stream. Clients SHOULD abort reading and discard data already read from push streams if no corresponding PUSH_PROMISE frame is processed in a reasonable amount of time.
並べ替えにより、対応するpush_promiseフレームの前にプッシュストリームデータが到着する可能性があります。クライアントが、まだ知られていないプッシュIDを備えた新しいプッシュストリームを受信すると、関連するクライアント要求とプッシュリクエストヘッダーフィールドの両方が不明です。クライアントは、一致するPush_promiseを期待してストリームデータをバッファリングできます。クライアントは、サーバーがプッシュされたストリームにコミットする可能性のあるデータの量を制限するために、ストリームフロー制御（[QUIC-Transport]のセクション4.1）を使用できます。クライアントは、対応するPush_promiseフレームが合理的な時間で処理されない場合、既にプッシュストリームから読み取りデータを読み取りおよび破棄する必要があります。
Push stream data can also arrive after a client has cancelled a push. In this case, the client can abort reading the stream with an error code of H3_REQUEST_CANCELLED. This asks the server not to transfer additional data and indicates that it will be discarded upon receipt.
クライアントがプッシュをキャンセルした後、プッシュストリームデータも到着する可能性があります。この場合、クライアントはH3_Request_Cancelledのエラーコードでストリームを読み取ることができます。これにより、サーバーは追加データを転送しないように求め、受領時に破棄されることを示します。
Pushed responses that are cacheable (see Section 3 of [HTTP-CACHING]) can be stored by the client, if it implements an HTTP cache. Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present; see Section 5.2.2.4 of [HTTP-CACHING]) at the time the pushed response is received.
キャッシュ可能なプッシュされた応答（[HTTPキャッシュ]のセクション3を参照）は、HTTPキャッシュを実装する場合、クライアントが保存できます。プッシュされた応答は、プッシュされた応答が受信された時点で、Origin Server（たとえば、「No-Cache」キャッシュ応答指令が存在する場合、[HTTPキャッシュ]のセクション5.2.2.4を参照）で正常に検証されていると見なされます。
Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY be made available to the application separately.
キャッシュできないプッシュされた応答は、HTTPキャッシュによって保存されてはなりません。それらは、アプリケーションで別々に利用可能になる場合があります。
Once established, an HTTP/3 connection can be used for many requests and responses over time until the connection is closed. Connection closure can happen in any of several different ways.
確立されると、接続が閉じられるまで、時間の経過とともに多くのリクエストと応答にHTTP/3接続を使用できます。接続閉鎖は、いくつかの異なる方法で発生する可能性があります。
Each QUIC endpoint declares an idle timeout during the handshake. If the QUIC connection remains idle (no packets received) for longer than this duration, the peer will assume that the connection has been closed. HTTP/3 implementations will need to open a new HTTP/3 connection for new requests if the existing connection has been idle for longer than the idle timeout negotiated during the QUIC handshake, and they SHOULD do so if approaching the idle timeout; see Section 10.1 of [QUIC-TRANSPORT].
各QUICエンドポイントは、握手中にアイドルタイムアウトを宣言します。QUIC接続がこの期間より長い間アイドル状態（パケットが受信されない）のままである場合、ピアは接続が閉じられていると想定します。HTTP/3実装は、既存の接続がQUICハンドシェイク中に交渉されたアイドルタイムアウトよりも長くアイドル状態である場合、新しいリクエストの新しいHTTP/3接続を開く必要があり、アイドルタイムアウトに近づく場合はそうする必要があります。[Quic-Transport]のセクション10.1を参照してください。
HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]. If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort maintaining a connection that might not be needed. A gateway MAY maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers. Servers SHOULD NOT actively keep connections open.
HTTPクライアントは、[QUIC-Transport]のセクション10.1.2で説明されているように、リクエストまたはサーバーのプッシュに対して未解決の応答がある間、トランスポートを開いたままにすることを要求することが期待されています。クライアントがサーバーからの応答を期待していない場合、必要とされていない接続を維持する努力を消費するよりも、タイムアウトへのアイドル接続を許可することが推奨されます。ゲートウェイは、サーバーへの接続確立の遅延コストを負うのではなく、ニーズを予想して接続を維持する場合があります。サーバーは、接続を積極的に開いたままにしてはなりません。
Even when a connection is not idle, either endpoint can decide to stop using the connection and initiate a graceful connection close. Endpoints initiate the graceful shutdown of an HTTP/3 connection by sending a GOAWAY frame. The GOAWAY frame contains an identifier that indicates to the receiver the range of requests or pushes that were or might be processed in this connection. The server sends a client-initiated bidirectional stream ID; the client sends a push ID. Requests or pushes with the indicated identifier or greater are rejected (Section 4.1.1) by the sender of the GOAWAY. This identifier MAY be zero if no requests or pushes were processed.
接続がアイドル状態でない場合でも、どちらのエンドポイントも接続の使用を停止し、優雅な接続を開始することを決定できます。エンドポイントは、Goawayフレームを送信することにより、HTTP/3接続の優雅なシャットダウンを開始します。Goawayフレームには、この関連で処理された、または処理される可能性のあるリクエストまたはプッシュの範囲を受信者に示す識別子が含まれています。サーバーは、クライアントが開始した双方向ストリームIDを送信します。クライアントはプッシュIDを送信します。指定された識別子以上のリクエストまたはプッシュは、Goawayの送信者によって拒否されます（セクション4.1.1）。リクエストまたはプッシュが処理されなかった場合、この識別子はゼロになる場合があります。
The information in the GOAWAY frame enables a client and server to agree on which requests or pushes were accepted prior to the shutdown of the HTTP/3 connection. Upon sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see Sections 4.1.1 and 7.2.3) any requests or pushes that have identifiers greater than or equal to the one indicated, in order to clean up transport state for the affected streams. The endpoint SHOULD continue to do so as more requests or pushes arrive.
GoAwayフレームの情報により、クライアントとサーバーは、HTTP/3接続のシャットダウンの前にどのリクエストまたはプッシュが受け入れられたかに同意することができます。Goawayフレームを送信すると、エンドポイントは、影響を受けるストリームの輸送状態をクリーンアップするために、示されている識別子以下の識別子を持つリクエストまたはプッシュを明示的にキャンセルする必要があります（セクション4.1.1および7.2.3を参照）。エンドポイントは、より多くのリクエストまたはプッシュが到着するにつれて、引き続きそうする必要があります。
Endpoints MUST NOT initiate new requests or promise new pushes on the connection after receipt of a GOAWAY frame from the peer. Clients MAY establish a new connection to send additional requests.
エンドポイントは、ピアからgoawayフレームを受け取った後、新しいリクエストを開始したり、接続の新しいプッシュを約束したりしてはなりません。クライアントは、追加のリクエストを送信するための新しい接続を確立する場合があります。
Some requests or pushes might already be in transit:
いくつかのリクエストまたはプッシュはすでに輸送中にある可能性があります：
* Upon receipt of a GOAWAY frame, if the client has already sent requests with a stream ID greater than or equal to the identifier contained in the GOAWAY frame, those requests will not be processed. Clients can safely retry unprocessed requests on a different HTTP connection. A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.
* Goawayフレームを受け取ると、クライアントがGoawayフレームに含まれる識別子以下のストリームIDを既にリクエストを送信している場合、それらのリクエストは処理されません。クライアントは、別のHTTP接続で未加工のリクエストを安全に再試行できます。リクエストを再試行できないクライアントは、サーバーが接続を閉じるときに飛行中のすべての要求を失います。
Requests on stream IDs less than the stream ID in a GOAWAY frame from the server might have been processed; their status cannot be known until a response is received, the stream is reset individually, another GOAWAY is received with a lower stream ID than that of the request in question, or the connection terminates.
サーバーからのGOAWAYフレームのストリームIDよりも少ないストリームIDのリクエストが処理された可能性があります。それらのステータスは、応答が受信されるまで、ストリームが個別にリセットされるか、問題のリクエストよりも低いストリームIDで別のゴーウェイが受信されるか、接続が終了するまではわかりません。
Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed.
サーバーは、これらのリクエストが処理されていない場合、指定されたIDの下のストリームで個々のリクエストを拒否する場合があります。
* If a server receives a GOAWAY frame after having promised pushes with a push ID greater than or equal to the identifier contained in the GOAWAY frame, those pushes will not be accepted.
* サーバーが、goawayフレームに含まれる識別子以上のプッシュIDでプッシュを約束した後にゲーウェイフレームを受信した場合、それらのプッシュは受け入れられません。
Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the remote peer can know whether or not a request has been partially processed. For example, if an HTTP client sends a POST at the same time that a server closes a QUIC connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on.
リモートピアがリクエストが部分的に処理されているかどうかを知ることができるように、事前通知が小さい場合でも、接続の閉鎖が事前に既知のときにGoawayフレームを送信する必要があります。たとえば、HTTPクライアントがサーバーがQUIC接続を閉じると同時に投稿を送信した場合、サーバーがgoawayフレームを送信してストリームを示さない場合、サーバーがその要求を処理し始めたかどうかをクライアントが知ることができません行動しました。
An endpoint MAY send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another HTTP connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR.
エンドポイントは、異なる識別子を示す複数のGoawayフレームを送信する場合がありますが、クライアントはすでに別のHTTP接続で未処理のリクエストを再試行している可能性があるため、各フレームの識別子は以前のフレームの識別子よりも大きくなければなりません。以前に受信したよりも大きな識別子を含むgoawayを受信することは、タイプH3_ID_ERRORの接続エラーとして扱わなければなりません。
An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible value (2^62-4 for servers, 2^62-1 for clients). This ensures that the peer stops creating new requests or pushes. After allowing time for any in-flight requests or pushes to arrive, the endpoint can send another GOAWAY frame indicating which requests or pushes it might accept before the end of the connection. This ensures that a connection can be cleanly shut down without losing requests.
接続を優雅にシャットダウンしようとしているエンドポイントは、値を最大値に設定したGoawayフレームを送信できます（サーバーでは2^62-4、クライアントの場合は2^62-1）。これにより、ピアが新しいリクエストまたはプッシュの作成を停止することが保証されます。飛行中のリクエストまたはプッシュが到着する時間を許可した後、エンドポイントは、接続の終了前にどのリクエストまたはプッシュを受け入れるかを示す別のgoawayフレームを送信できます。これにより、リクエストを失うことなく接続をきれいにシャットダウンできるようになります。
A client has more flexibility in the value it chooses for the Push ID field in a GOAWAY that it sends. A value of 2^62-1 indicates that the server can continue fulfilling pushes that have already been promised. A smaller value indicates the client will reject pushes with push IDs greater than or equal to this value. Like the server, the client MAY send subsequent GOAWAY frames so long as the specified push ID is no greater than any previously sent value.
クライアントは、送信する移動中のプッシュIDフィールドに選択した値の柔軟性を高めます。2^62-1の値は、すでに約束されているプッシュを履行し続けることができることを示しています。値が小さいことは、クライアントがこの値以上のプッシュIDでプッシュを拒否することを示します。サーバーと同様に、クライアントは、指定されたプッシュIDが以前に送信された値よりも大きくない限り、後続のGoAwayフレームを送信する場合があります。
Even when a GOAWAY indicates that a given request or push will not be processed or accepted upon receipt, the underlying transport resources still exist. The endpoint that initiated these requests can cancel them to clean up transport state.
Goawayが特定のリクエストまたはプッシュが受領時に処理または受け入れられないことを示している場合でも、基礎となる輸送リソースはまだ存在します。これらの要求を開始したエンドポイントは、それらをキャンセルして輸送状態をクリーンアップすることができます。
Once all accepted requests and pushes have been processed, the endpoint can permit the connection to become idle, or it MAY initiate an immediate closure of the connection. An endpoint that completes a graceful shutdown SHOULD use the H3_NO_ERROR error code when closing the connection.
受け入れられたすべてのリクエストとプッシュが処理されると、エンドポイントは接続をアイドル状態にすることができます。または、接続の即時閉鎖を開始する可能性があります。優雅なシャットダウンを完了するエンドポイントは、接続を閉じるときにH3_NO_ERRORエラーコードを使用する必要があります。
If a client has consumed all available bidirectional stream IDs with requests, the server need not send a GOAWAY frame, since the client is unable to make further requests.
クライアントがリクエストを使用して利用可能なすべての双方向ストリームIDを消費している場合、クライアントはさらにリクエストを行うことができないため、サーバーはgoawayフレームを送信する必要はありません。
An HTTP/3 implementation can immediately close the QUIC connection at any time. This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicating that the application layer has terminated the connection. The application error code in this frame indicates to the peer why the connection is being closed. See Section 8 for error codes that can be used when closing a connection in HTTP/3.
HTTP/3の実装は、いつでもQUIC接続をすぐに閉じることができます。これにより、QUIC Connection_Closeフレームをピアに送信して、アプリケーションレイヤーが接続を終了したことを示します。このフレームのアプリケーションエラーコードは、接続が閉じられている理由をピアに示します。HTTP/3の接続を閉じるときに使用できるエラーコードについては、セクション8を参照してください。
Before closing the connection, a GOAWAY frame MAY be sent to allow the client to retry some requests. Including the GOAWAY frame in the same packet as the QUIC CONNECTION_CLOSE frame improves the chances of the frame being received by clients.
接続を閉じる前に、クライアントがいくつかのリクエストを再試行できるようにするために、Goawayフレームを送信することができます。quic connection_closeフレームと同じパケットにgoawayフレームを含めることで、クライアントが受信するフレームが受信される可能性が向上します。
If there are open streams that have not been explicitly closed, they are implicitly closed when the connection is closed; see Section 10.2 of [QUIC-TRANSPORT].
明示的に閉じられていないオープンストリームがある場合、接続が閉じたときに暗黙的に閉じられます。[Quic-Transport]のセクション10.2を参照してください。
For various reasons, the QUIC transport could indicate to the application layer that the connection has terminated. This might be due to an explicit closure by the peer, a transport-level error, or a change in network topology that interrupts connectivity.
さまざまな理由で、QUICトランスポートは、接続が終了したアプリケーションレイヤーに示す可能性があります。これは、ピアによる明示的な閉鎖、トランスポートレベルのエラー、または接続性を妨げるネットワークトポロジの変更による可能性があります。
If a connection terminates without a GOAWAY frame, clients MUST assume that any request that was sent, whether in whole or in part, might have been processed.
接続がgoawayフレームなしで終了する場合、クライアントは、全体または一部が処理されている可能性があるかどうかにかかわらず、送信されたリクエストがすべて処理されている可能性があると想定する必要があります。
A QUIC stream provides reliable in-order delivery of bytes, but makes no guarantees about order of delivery with regard to bytes on other streams. In version 1 of QUIC, the stream data containing HTTP frames is carried by QUIC STREAM frames, but this framing is invisible to the HTTP framing layer. The transport layer buffers and orders received stream data, exposing a reliable byte stream to the application. Although QUIC permits out-of-order delivery within a stream, HTTP/3 does not make use of this feature.
QUICストリームは、バイトの信頼性の高い注文内配信を提供しますが、他のストリームのバイトに関する配信の順序について保証しません。QUICのバージョン1では、HTTPフレームを含むストリームデータはQUICストリームフレームによって運ばれますが、このフレーミングはHTTPフレーミングレイヤーには見えません。輸送層バッファと注文は、ストリームデータを受け取り、信頼できるバイトストリームをアプリケーションに公開しました。QUICはストリーム内での注文外配信を許可しますが、HTTP/3はこの機能を使用していません。
QUIC streams can be either unidirectional, carrying data only from initiator to receiver, or bidirectional, carrying data in both directions. Streams can be initiated by either the client or the server. For more detail on QUIC streams, see Section 2 of [QUIC-TRANSPORT].
QUICストリームは、イニシエーターから受信機までのみデータを運ぶか、または両方向にデータをbidirectionalに運ぶことができます。ストリームは、クライアントまたはサーバーのいずれかによって開始できます。QUICストリームの詳細については、[Quic-Transport]のセクション2を参照してください。
When HTTP fields and data are sent over QUIC, the QUIC layer handles most of the stream management. HTTP does not need to do any separate multiplexing when using QUIC: data sent over a QUIC stream always maps to a particular HTTP transaction or to the entire HTTP/3 connection context.
HTTPフィールドとデータがQUICを介して送信されると、QUICレイヤーはほとんどのストリーム管理を処理します。HTTPは、QUICを使用する場合、個別の多重化を行う必要はありません。QUICストリームを介して送信されたデータは、常に特定のHTTPトランザクションまたはHTTP/3接続コンテキスト全体にマップします。
All client-initiated bidirectional streams are used for HTTP requests and responses. A bidirectional stream ensures that the response can be readily correlated with the request. These streams are referred to as request streams.
すべてのクライアントが開始する双方向ストリームは、HTTP要求と応答に使用されます。双方向のストリームにより、応答がリクエストと容易に相関することが保証されます。これらのストリームは、要求ストリームと呼ばれます。
This means that the client's first request occurs on QUIC stream 0, with subsequent requests on streams 4, 8, and so on. In order to permit these streams to open, an HTTP/3 server SHOULD configure non-zero minimum values for the number of permitted streams and the initial stream flow-control window. So as to not unnecessarily limit parallelism, at least 100 request streams SHOULD be permitted at a time.
これは、クライアントの最初の要求がQUICストリーム0で発生し、その後のリクエストがストリーム4、8などで発生することを意味します。これらのストリームを開くことを許可するために、HTTP/3サーバーは、許可されたストリームの数と初期ストリームフローコントロールウィンドウの非ゼロの最小値を構成する必要があります。不必要に並列性を制限しないように、少なくとも100の要求ストリームを一度に許可する必要があります。
HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams. Clients MUST treat receipt of a server-initiated bidirectional stream as a connection error of type H3_STREAM_CREATION_ERROR unless such an extension has been negotiated.
HTTP/3は、サーバーが開始した双方向ストリームを使用しませんが、拡張機能はこれらのストリームの使用を定義できます。クライアントは、そのような拡張機能が交渉されていない限り、サーバー開始の双方向ストリームの受領をタイプH3_Stream_Creation_Errorの接続エラーとして扱う必要があります。
Unidirectional streams, in either direction, are used for a range of purposes. The purpose is indicated by a stream type, which is sent as a variable-length integer at the start of the stream. The format and structure of data that follows this integer is determined by the stream type.
どちらの方向でも、一方向のストリームは、さまざまな目的に使用されます。目的は、ストリームの開始時に可変長整数として送信されるストリームタイプで示されます。この整数に続くデータの形式と構造は、ストリームタイプによって決定されます。
Unidirectional Stream Header {
Stream Type (i),
}
Figure 1: Unidirectional Stream Header
図1：単方向ストリームヘッダー
Two stream types are defined in this document: control streams (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines two additional stream types. Other stream types can be defined by extensions to HTTP/3; see Section 9 for more details. Some stream types are reserved (Section 6.2.3).
このドキュメントでは、2つのストリームタイプが定義されています：制御ストリーム（セクション6.2.1）とプッシュストリーム（セクション6.2.2）。[QPack]は、2つの追加のストリームタイプを定義します。他のストリームタイプは、http/3の拡張機能によって定義できます。詳細については、セクション9を参照してください。一部のストリームタイプは予約されています（セクション6.2.3）。
The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on unidirectional streams. Endpoints that excessively restrict the number of streams or the flow-control window of these streams will increase the chance that the remote peer reaches the limit early and becomes blocked. In particular, implementations should consider that remote peers may wish to exercise reserved stream behavior (Section 6.2.3) with some of the unidirectional streams they are permitted to use.
寿命の初期段階でのHTTP/3接続のパフォーマンスは、単方向のストリーム上のデータの作成と交換に敏感です。これらのストリームのストリームの数またはフローコントロールウィンドウを過度に制限するエンドポイントは、リモートピアが早期に制限に達してブロックされる可能性を高めます。特に、実装は、リモートピアが使用することが許可されている単方向のストリームのいくつかを使用して、予約されたストリーム動作（セクション6.2.3）を行使したいと考えている必要があります。
Each endpoint needs to create at least one unidirectional stream for the HTTP control stream. QPACK requires two additional unidirectional streams, and other extensions might require further streams. Therefore, the transport parameters sent by both clients and servers MUST allow the peer to create at least three unidirectional streams. These transport parameters SHOULD also provide at least 1,024 bytes of flow-control credit to each unidirectional stream.
各エンドポイントは、HTTP制御ストリームの少なくとも1つの単方向ストリームを作成する必要があります。QPACKには2つの追加の単方向ストリームが必要であり、他の拡張機能にはさらなるストリームが必要になる場合があります。したがって、クライアントとサーバーの両方から送信される輸送パラメーターは、ピアが少なくとも3つの単方向のストリームを作成できるようにする必要があります。これらの輸送パラメーターは、各単方向ストリームに少なくとも1,024バイトのフローコントロールクレジットを提供する必要があります。
Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the initial credits before creating the critical unidirectional streams. Endpoints SHOULD create the HTTP control stream as well as the unidirectional streams required by mandatory extensions (such as the QPACK encoder and decoder streams) first, and then create additional streams as allowed by their peer.
重要な単方向ストリームを作成する前に、ピアがすべての初期クレジットを消費する場合、より多くの単方向ストリームを作成するために追加のクレジットを付与するためにエンドポイントが必要ではないことに注意してください。エンドポイントは、必須の拡張機能（QPACKエンコーダーやデコーダーストリームなど）に必要なHTTP制御ストリームと単方向ストリームを最初に作成し、次にピアが許可された追加のストリームを作成する必要があります。
If the stream header indicates a stream type that is not supported by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown. Recipients of unknown stream types MUST either abort reading of the stream or discard incoming data without further processing. If reading is aborted, the recipient SHOULD use the H3_STREAM_CREATION_ERROR error code or a reserved error code (Section 8.1). The recipient MUST NOT consider unknown stream types to be a connection error of any kind.
ストリームヘッダーが受信者によってサポートされていないストリームタイプを示している場合、セマンティクスが不明であるため、ストリームの残りの部分は消費できません。未知のストリームタイプの受信者は、ストリームの読み取りを中止するか、さらに処理することなく着信データを破棄する必要があります。読み取りが中止されている場合、受信者はh3_stream_creation_errorエラーコードまたは予約されたエラーコード（セクション8.1）を使用する必要があります。受信者は、不明なストリームタイプをあらゆる種類の接続エラーと見なしてはなりません。
As certain stream types can affect connection state, a recipient SHOULD NOT discard data from incoming unidirectional streams prior to reading the stream type.
特定のストリームタイプは接続状態に影響を与える可能性があるため、受信者は、ストリームタイプを読む前に、着信単方向のストリームからデータを破棄してはなりません。
Implementations MAY send stream types before knowing whether the peer supports them. However, stream types that could modify the state or semantics of existing protocol components, including QPACK or other extensions, MUST NOT be sent until the peer is known to support them.
実装は、ピアがそれらをサポートするかどうかを知る前に、ストリームタイプを送信する場合があります。ただし、QPACKやその他の拡張機能を含む既存のプロトコルコンポーネントの状態またはセマンティクスを変更できるストリームタイプは、ピアがそれらをサポートすることが知られるまで送信してはなりません。
A sender can close or reset a unidirectional stream unless otherwise specified. A receiver MUST tolerate unidirectional streams being closed or reset prior to the reception of the unidirectional stream header.
送信者は、特に指定されていない限り、単方向ストリームを閉じるかリセットできます。レシーバーは、単方向のストリームヘッダーを受信する前に、一方向のストリームを閉じたりリセットしたりする必要があります。
A control stream is indicated by a stream type of 0x00. Data on this stream consists of HTTP/3 frames, as defined in Section 7.2.
制御ストリームは、0x00のストリームタイプで示されます。このストリームのデータは、セクション7.2で定義されているように、HTTP/3フレームで構成されています。
Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream. If the first frame of the control stream is any other frame type, this MUST be treated as a connection error of type H3_MISSING_SETTINGS. Only one control stream per peer is permitted; receipt of a second stream claiming to be a control stream MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR. The sender MUST NOT close the control stream, and the receiver MUST NOT request that the sender close the control stream. If either control stream is closed at any point, this MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are described in Section 8.
各側は、接続の先頭に単一の制御ストリームを開始し、このストリームの最初のフレームとして設定フレームを送信する必要があります。制御ストリームの最初のフレームが他のフレームタイプである場合、これはタイプh3_missing_settingsの接続エラーとして扱う必要があります。ピアごとに1つのコントロールストリームのみが許可されています。コントロールストリームであると主張する2番目のストリームの受領は、タイプH3_STREAM_CREATION_ERRORの接続エラーとして扱わなければなりません。送信者は制御ストリームを閉じてはなりません。受信者は、送信者がコントロールストリームを閉じることを要求してはなりません。いずれかのコントロールストリームが任意の時点で閉じている場合、これはタイプh3_closed_critical_streamの接続エラーとして扱わなければなりません。接続エラーについては、セクション8で説明します。
Because the contents of the control stream are used to manage the behavior of other streams, endpoints SHOULD provide enough flow-control credit to keep the peer's control stream from becoming blocked.
制御ストリームの内容は、他のストリームの動作を管理するために使用されるため、エンドポイントは、ピアのコントロールストリームがブロックされないように十分なフロー制御クレジットを提供する必要があります。
A pair of unidirectional streams is used rather than a single bidirectional stream. This allows either peer to send data as soon as it is able. Depending on whether 0-RTT is available on the QUIC connection, either client or server might be able to send stream data first.
単一の双方向のストリームではなく、一対の単方向ストリームが使用されます。これにより、どちらかのピアができるだけ早くデータを送信できます。0-RTTがQUIC接続で利用可能かどうかに応じて、クライアントまたはサーバーのいずれかが最初にストリームデータを送信できる可能性があります。
Server push is an optional feature introduced in HTTP/2 that allows a server to initiate a response before a request has been made. See Section 4.6 for more details.
サーバープッシュは、HTTP/2で導入されたオプションの機能であり、リクエストが行われる前にサーバーが応答を開始できるようにします。詳細については、セクション4.6を参照してください。
A push stream is indicated by a stream type of 0x01, followed by the push ID of the promise that it fulfills, encoded as a variable-length integer. The remaining data on this stream consists of HTTP/3 frames, as defined in Section 7.2, and fulfills a promised server push by zero or more interim HTTP responses followed by a single final HTTP response, as defined in Section 4.1. Server push and push IDs are described in Section 4.6.
プッシュストリームは、0x01のストリームタイプで示され、その後、可変長整数としてエンコードされるという約束のプッシュIDが続きます。このストリームの残りのデータは、セクション7.2で定義されているHTTP/3フレームで構成されており、セクション4.1で定義されているように、ゼロ以上の暫定HTTP応答による約束のサーバープッシュとその後の単一の最終HTTP応答を満たします。サーバープッシュおよびプッシュIDは、セクション4.6で説明されています。
Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR.
サーバーのみがプッシュできます。サーバーがクライアントが開始したプッシュストリームを受信した場合、これはタイプh3_stream_creation_errorの接続エラーとして扱う必要があります。
Push Stream Header {
Stream Type (i) = 0x01,
Push ID (i),
}
Figure 2: Push Stream Header
図2：プッシュストリームヘッダー
A client SHOULD NOT abort reading on a push stream prior to reading the push stream header, as this could lead to disagreement between client and server on which push IDs have already been consumed.
クライアントは、プッシュストリームヘッダーを読む前にプッシュストリームを読み取るべきではありません。これは、プッシュIDがすでに消費されているクライアントとサーバーの間で意見の相違につながる可能性があるためです。
Each push ID MUST only be used once in a push stream header. If a client detects that a push stream header includes a push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR.
各プッシュIDは、プッシュストリームヘッダーで1回のみ使用する必要があります。クライアントがプッシュストリームヘッダーに別のプッシュストリームヘッダーで使用されたプッシュIDが含まれていることを検出した場合、クライアントはこれをタイプH3_ID_ERRORの接続エラーとして扱う必要があります。
Stream types of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored. These streams have no semantics, and they can be sent when application-layer padding is desired. They MAY also be sent on connections where no data is currently being transferred. Endpoints MUST NOT consider these streams to have any meaning upon receipt.
nの非陰性整数値の形式0x1f * n 0x21のストリームタイプは、未知のタイプを無視するという要件を行使するために予約されています。これらのストリームにはセマンティクスがなく、アプリケーションレイヤーパディングが必要な場合に送信できます。また、現在データが転送されていない接続に送信される場合があります。エンドポイントは、これらのストリームを領収書時に意味があると考慮してはなりません。
The payload and length of the stream are selected in any manner the sending implementation chooses. When sending a reserved stream type, the implementation MAY either terminate the stream cleanly or reset it. When resetting the stream, either the H3_NO_ERROR error code or a reserved error code (Section 8.1) SHOULD be used.
ストリームのペイロードと長さは、送信の実装が選択するあらゆる方法で選択されます。予約済みのストリームタイプを送信すると、実装はストリームをきれいに終了するか、リセットする場合があります。ストリームをリセットするときは、H3_NO_ERRORエラーコードまたは予約されたエラーコード（セクション8.1）を使用する必要があります。
HTTP frames are carried on QUIC streams, as described in Section 6. HTTP/3 defines three stream types: control stream, request stream, and push stream. This section describes HTTP/3 frame formats and their permitted stream types; see Table 1 for an overview. A comparison between HTTP/2 and HTTP/3 frames is provided in Appendix A.2.
HTTPフレームは、セクション6で説明されているように、QUICストリームで運ばれます。HTTP/3は、制御ストリーム、要求ストリーム、プッシュストリームの3つのストリームタイプを定義します。このセクションでは、HTTP/3フレーム形式と許可されたストリームタイプについて説明します。概要については、表1を参照してください。HTTP/2とHTTP/3フレームの比較は、付録A.2に記載されています。
+==============+================+================+========+=========+
| Frame | Control Stream | Request | Push | Section |
| | | Stream | Stream | |
+==============+================+================+========+=========+
| DATA | No | Yes | Yes | Section |
| | | | | 7.2.1 |
+--------------+----------------+----------------+--------+---------+
| HEADERS | No | Yes | Yes | Section |
| | | | | 7.2.2 |
+--------------+----------------+----------------+--------+---------+
| CANCEL_PUSH | Yes | No | No | Section |
| | | | | 7.2.3 |
+--------------+----------------+----------------+--------+---------+
| SETTINGS | Yes (1) | No | No | Section |
| | | | | 7.2.4 |
+--------------+----------------+----------------+--------+---------+
| PUSH_PROMISE | No | Yes | No | Section |
| | | | | 7.2.5 |
+--------------+----------------+----------------+--------+---------+
| GOAWAY | Yes | No | No | Section |
| | | | | 7.2.6 |
+--------------+----------------+----------------+--------+---------+
| MAX_PUSH_ID | Yes | No | No | Section |
| | | | | 7.2.7 |
+--------------+----------------+----------------+--------+---------+
| Reserved | Yes | Yes | Yes | Section |
| | | | | 7.2.8 |
+--------------+----------------+----------------+--------+---------+
Table 1: HTTP/3 Frames and Stream Type Overview
表1：HTTP/3フレームとストリームタイプの概要
The SETTINGS frame can only occur as the first frame of a Control stream; this is indicated in Table 1 with a (1). Specific guidance is provided in the relevant section.
設定フレームは、制御ストリームの最初のフレームとしてのみ発生します。これは、A（1）の表1に示されています。特定のセクションで特定のガイダンスが提供されています。
Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets.
QUICフレームとは異なり、HTTP/3フレームは複数のパケットにまたがる可能性があることに注意してください。
All frames have the following format:
すべてのフレームには次の形式があります。
HTTP/3 Frame Format {
Type (i),
Length (i),
Frame Payload (..),
}
Figure 3: HTTP/3 Frame Format
図3：HTTP/3フレーム形式
A frame includes the following fields:
フレームには次のフィールドが含まれます。
Type: A variable-length integer that identifies the frame type.
タイプ：フレームタイプを識別する可変長整数。
Length: A variable-length integer that describes the length in bytes of the Frame Payload.
長さ：フレームペイロードのバイトの長さを記述する可変長整数。
Frame Payload: A payload, the semantics of which are determined by the Type field.
フレームペイロード：ペイロード。そのセマンティクスは、タイプフィールドによって決定されます。
Each frame's payload MUST contain exactly the fields identified in its description. A frame payload that contains additional bytes after the identified fields or a frame payload that terminates before the end of the identified fields MUST be treated as a connection error of type H3_FRAME_ERROR. In particular, redundant length encodings MUST be verified to be self-consistent; see Section 10.8.
各フレームのペイロードには、その説明で識別されたフィールドを正確に含める必要があります。識別されたフィールドの後に追加のバイトを含むフレームペイロードまたは識別されたフィールドの終了前に終了するフレームペイロードは、タイプh3_frame_errorの接続エラーとして扱わなければなりません。特に、冗長な長さのエンコーディングは、自己整合性であることを確認する必要があります。セクション10.8を参照してください。
When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error of type H3_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in a frame.
ストリームがきれいに終了すると、ストリーム上の最後のフレームが切り捨てられた場合、これはタイプh3_frame_errorの接続エラーとして扱わなければなりません。突然終了するストリームは、フレーム内の任意の時点でリセットされる場合があります。
DATA frames (type=0x00) convey arbitrary, variable-length sequences of bytes associated with HTTP request or response content.
データフレーム（Type = 0x00）は、HTTP要求または応答コンテンツに関連付けられたバイトの任意の可変長さのシーケンスを伝えます。
DATA frames MUST be associated with an HTTP request or response. If a DATA frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
データフレームは、HTTPリクエストまたは応答に関連付けられている必要があります。データフレームがコントロールストリームで受信された場合、受信者はタイプh3_frame_unexpectedの接続エラーで応答する必要があります。
DATA Frame {
Type (i) = 0x00,
Length (i),
Data (..),
}
Figure 4: DATA Frame
図4：データフレーム
The HEADERS frame (type=0x01) is used to carry an HTTP field section that is encoded using QPACK. See [QPACK] for more details.
ヘッダーフレーム（Type = 0x01）は、QPackを使用してエンコードされたHTTPフィールドセクションを運ぶために使用されます。詳細については、[QPack]を参照してください。
HEADERS Frame {
Type (i) = 0x01,
Length (i),
Encoded Field Section (..),
}
Figure 5: HEADERS Frame
図5：ヘッダーフレーム
HEADERS frames can only be sent on request streams or push streams. If a HEADERS frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
ヘッダーフレームは、リクエストストリームまたはプッシュストリームに従ってのみ送信できます。ヘッダーフレームがコントロールストリームで受信された場合、受信者はタイプh3_frame_unexpectedの接続エラーで応答する必要があります。
The CANCEL_PUSH frame (type=0x03) is used to request cancellation of a server push prior to the push stream being received. The CANCEL_PUSH frame identifies a server push by push ID (see Section 4.6), encoded as a variable-length integer.
cancel_pushフレーム（type = 0x03）は、プッシュストリームが受信される前にサーバープッシュのキャンセルを要求するために使用されます。cancel_pushフレームは、可変長整数としてエンコードされたプッシュID（セクション4.6を参照）によるサーバープッシュを識別します。
When a client sends a CANCEL_PUSH frame, it is indicating that it does not wish to receive the promised resource. The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream. If the server has not yet created a push stream, it does not create one. If the push stream is open, the server SHOULD abruptly terminate that stream. If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action.
クライアントがcancel_pushフレームを送信すると、約束されたリソースを受信したくないことが示されています。サーバーはリソースの送信を中止する必要がありますが、そうするメカニズムは、対応するプッシュストリームの状態に依存します。サーバーがまだプッシュストリームを作成していない場合、それは作成しません。プッシュストリームが開いている場合、サーバーはそのストリームを突然終了する必要があります。プッシュストリームが既に終了している場合、サーバーは依然としてストリームを突然終了するか、アクションを実行しない場合があります。
A server sends a CANCEL_PUSH frame to indicate that it will not be fulfilling a promise that was previously sent. The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response. Regardless of whether a push stream has been opened, a server SHOULD send a CANCEL_PUSH frame when it determines that promise will not be fulfilled. If a stream has already been opened, the server can abort sending on the stream with an error code of H3_REQUEST_CANCELLED.
サーバーは、cancel_pushフレームを送信して、以前に送信された約束を満たさないことを示します。クライアントは、既に約束された応答を受け取って処理していない限り、対応する約束が満たされることを期待することはできません。プッシュストリームが開かれたかどうかに関係なく、サーバーは、約束が満たされないと判断した場合にcancel_pushフレームを送信する必要があります。ストリームがすでに開いている場合、サーバーはH3_Request_Cancelledのエラーコードでストリームを送信することができます。
Sending a CANCEL_PUSH frame has no direct effect on the state of existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame when it has already received a corresponding push stream. A push stream could arrive after a client has sent a CANCEL_PUSH frame, because a server might not have processed the CANCEL_PUSH. The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED.
cancel_pushフレームの送信は、既存のプッシュストリームの状態に直接的な影響を与えません。クライアントは、対応するプッシュストリームを既に受信している場合、cancel_pushフレームを送信しないでください。サーバーがcancel_pushを処理していない可能性があるため、クライアントがcancel_pushフレームを送信した後にプッシュストリームが到着する可能性があります。クライアントは、h3_request_cancelledのエラーコードでストリームを読み取ることを中止する必要があります。
A CANCEL_PUSH frame is sent on the control stream. Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Cancel_Pushフレームがコントロールストリームに送信されます。制御ストリーム以外のストリームでCancel_Pushフレームを受信することは、タイプh3_frame_unexpectedの接続エラーとして扱う必要があります。
CANCEL_PUSH Frame {
Type (i) = 0x03,
Length (i),
Push ID (i),
}
Figure 6: CANCEL_PUSH Frame
図6：cancel_pushフレーム
The CANCEL_PUSH frame carries a push ID encoded as a variable-length integer. The Push ID field identifies the server push that is being cancelled; see Section 4.6. If a CANCEL_PUSH frame is received that references a push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type H3_ID_ERROR.
cancel_pushフレームには、可変長整数としてエンコードされたプッシュIDが搭載されています。プッシュIDフィールドは、キャンセルされているサーバープッシュを識別します。セクション4.6を参照してください。接続で現在許可されているよりも大きいプッシュIDを参照するCANCEL_PUSHフレームが受信された場合、これはタイプH3_ID_ERRORの接続エラーとして扱う必要があります。
If the client receives a CANCEL_PUSH frame, that frame might identify a push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering. If a server receives a CANCEL_PUSH frame for a push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type H3_ID_ERROR.
クライアントがcancel_pushフレームを受信した場合、そのフレームは、並べ替えのためにpush_promiseフレームによってまだ言及されていないプッシュIDを識別する場合があります。サーバーがPush_promiseフレームでまだ言及されていないプッシュIDのcancel_pushフレームを受信した場合、これはタイプh3_id_errorの接続エラーとして扱う必要があります。
The SETTINGS frame (type=0x04) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior. Individually, a SETTINGS parameter can also be referred to as a "setting"; the identifier and value of each setting parameter can be referred to as a "setting identifier" and a "setting value".
設定フレーム（Type = 0x04）は、ピアの動作に対する好みや制約など、エンドポイントの通信方法に影響する構成パラメーターを伝えます。個別に、設定パラメーターは「設定」と呼ぶこともできます。各設定パラメーターの識別子と値は、「設定識別子」と「設定値」と呼ぶことができます。
SETTINGS frames always apply to an entire HTTP/3 connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and it MUST NOT be sent subsequently. If an endpoint receives a second SETTINGS frame on the control stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
設定フレームは常にHTTP/3接続全体に適用されますが、決して単一のストリームではありません。各ピアによって各コントロールストリームの最初のフレーム（セクション6.2.1を参照）として設定フレームを送信する必要があります。その後、送信してはなりません。エンドポイントが制御ストリームの2番目の設定フレームを受信した場合、エンドポイントはタイプh3_frame_unexpectedの接続エラーで応答する必要があります。
SETTINGS frames MUST NOT be sent on any stream other than the control stream. If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
設定フレームは、制御ストリーム以外のストリームに送信してはなりません。エンドポイントが別のストリームで設定フレームを受信した場合、エンドポイントは、タイプh3_frame_unexpectedの接続エラーで応答する必要があります。
SETTINGS parameters are not negotiated; they describe characteristics of the sending peer that can be used by the receiving peer. However, a negotiation can be implied by the use of SETTINGS: each peer uses SETTINGS to advertise a set of supported values. The definition of the setting would describe how each peer combines the two sets to conclude which choice will be used. SETTINGS does not provide a mechanism to identify when the choice takes effect.
設定パラメーターは交渉されません。彼らは、受信ピアが使用できる送信ピアの特性を説明しています。ただし、交渉は設定の使用によって暗示される可能性があります。各ピアは設定を使用して、サポートされた値のセットを宣伝します。設定の定義では、各ピアが2つのセットをどのように組み合わせて使用するかを説明します。設定は、選択が有効になる時期を識別するメカニズムを提供しません。
Different values for the same parameter can be advertised by each peer. For example, a client might be willing to consume a very large response field section, while servers are more cautious about request size.
同じパラメーターの異なる値は、各ピアによって宣伝できます。たとえば、クライアントは非常に大きな応答フィールドセクションを消費することをいとわない場合がありますが、サーバーはリクエストサイズについてより慎重です。
The same setting identifier MUST NOT occur more than once in the SETTINGS frame. A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type H3_SETTINGS_ERROR.
同じ設定識別子は、設定フレームで1回以上発生してはなりません。受信者は、型h3_settings_errorの接続エラーとして、複製設定識別子の存在を扱うことができます。
The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both encoded as QUIC variable-length integers.
設定フレームのペイロードは、ゼロ以上のパラメーターで構成されています。各パラメーターは、設定識別子と値の両方で構成されており、どちらもQUIC変数長整数としてエンコードされています。
Setting {
Identifier (i),
Value (i),
}
SETTINGS Frame {
Type (i) = 0x04,
Length (i),
Setting (..) ...,
}
Figure 7: SETTINGS Frame
図7：設定フレーム
An implementation MUST ignore any parameter with an identifier it does not understand.
実装は、理解できない識別子を使用してパラメーターを無視する必要があります。
The following settings are defined in HTTP/3:
次の設定は、http/3で定義されています。
SETTINGS_MAX_FIELD_SECTION_SIZE (0x06): The default value is unlimited. See Section 4.2.2 for usage.
settings_max_field_section_size（0x06）：デフォルト値は無制限です。使用については、セクション4.2.2を参照してください。
Setting identifiers of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown identifiers be ignored. Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their SETTINGS frame. Endpoints MUST NOT consider such settings to have any meaning upon receipt.
nの非陰性整数値の形式0x1f * n 0x21の識別子の設定は、未知の識別子を無視するという要件を行使するために予約されています。このような設定には、定義された意味がありません。エンドポイントには、設定フレームに少なくとも1つの設定を含める必要があります。エンドポイントは、そのような設定を領収書に意味があることを考慮してはなりません。
Because the setting has no defined meaning, the value of the setting can be any value the implementation selects.
設定には定義された意味がないため、設定の値は、実装が選択する任意の値になります。
Setting identifiers that were defined in [HTTP/2] where there is no corresponding HTTP/3 setting have also been reserved (Section 11.2.2). These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR.
対応するHTTP/3設定がない[HTTP/2]で定義された識別子の設定も予約されています（セクション11.2.2）。これらの予約された設定は送信されてはならず、領収書はタイプh3_settings_errorの接続エラーとして扱う必要があります。
Additional settings can be defined by extensions to HTTP/3; see Section 9 for more details.
追加の設定は、http/3の拡張機能によって定義できます。詳細については、セクション9を参照してください。
An HTTP implementation MUST NOT send frames or requests that would be invalid based on its current understanding of the peer's settings.
HTTP実装は、ピアの設定の現在の理解に基づいて無効になるフレームまたはリクエストを送信してはなりません。
All settings begin at an initial value. Each endpoint SHOULD use these initial values to send messages before the peer's SETTINGS frame has arrived, as packets carrying the settings can be lost or delayed. When the SETTINGS frame arrives, any settings are changed to their new values.
すべての設定は初期値から始まります。各エンドポイントは、これらの初期値を使用して、設定を運ぶパケットが失われたり遅延したりする可能性があるため、ピアの設定フレームが到着する前にメッセージを送信する必要があります。設定フレームが到着すると、設定は新しい値に変更されます。
This removes the need to wait for the SETTINGS frame before sending messages. Endpoints MUST NOT require any data to be received from the peer prior to sending the SETTINGS frame; settings MUST be sent as soon as the transport is ready to send data.
これにより、メッセージを送信する前に設定フレームを待つ必要があります。エンドポイントは、設定フレームを送信する前に、ピアからデータを受信する必要はありません。輸送がデータを送信する準備ができたらすぐに設定を送信する必要があります。
For servers, the initial value of each client setting is the default value.
サーバーの場合、各クライアント設定の初期値はデフォルト値です。
For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value. 1-RTT keys will always become available prior to the packet containing SETTINGS being processed by QUIC, even if the server sends SETTINGS immediately. Clients SHOULD NOT wait indefinitely for SETTINGS to arrive before sending requests, but they SHOULD process received datagrams in order to increase the likelihood of processing SETTINGS before sending the first request.
1-RTT QUIC接続を使用しているクライアントの場合、各サーバー設定の初期値はデフォルト値です。サーバーがすぐに設定を送信した場合でも、1-RTTキーは、QUICで処理される設定を含むパケットを含むパケットを含む前に、常に利用可能になります。クライアントは、リクエストを送信する前に設定が到着するのを無期限に待つべきではありませんが、最初のリクエストを送信する前に設定を処理する可能性を高めるために、受信したデータグラムを処理する必要があります。
When a 0-RTT QUIC connection is being used, the initial value of each server setting is the value used in the previous session. Clients SHOULD store the settings the server provided in the HTTP/3 connection where resumption information was provided, but they MAY opt not to store settings in certain cases (e.g., if the session ticket is received before the SETTINGS frame). A client MUST comply with stored settings -- or default values if no values are stored -- when attempting 0-RTT. Once a server has provided new settings, clients MUST comply with those values.
0-RTT QUIC接続が使用されている場合、各サーバー設定の初期値は、前のセッションで使用される値です。クライアントは、再開情報が提供されたHTTP/3接続にサーバーが提供する設定を保存する必要がありますが、特定の場合に設定を保存しないことを選択できます（たとえば、設定フレームの前にセッションチケットが受信された場合）。クライアントは、0-RTTを試みたときに、保存された設定、または値が保存されていない場合はデフォルト値を遵守する必要があります。サーバーが新しい設定を提供したら、クライアントはそれらの値に準拠する必要があります。
A server can remember the settings that it advertised or store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the HTTP/3 settings values in determining whether to accept 0-RTT data. If the server cannot determine that the settings remembered by a client are compatible with its current settings, it MUST NOT accept 0-RTT data. Remembered settings are compatible if a client complying with those settings would not violate the server's current settings.
サーバーは、チケット内の値の整合性保護されたコピーを宣伝した設定を覚えているか、0-RTTデータを受け入れるときに情報を回復することができます。サーバーは、0-RTTデータを受け入れるかどうかを決定する際に、HTTP/3設定値を使用します。クライアントが記憶している設定が現在の設定と互換性があることをサーバーが判断できない場合、0-RTTデータを受け入れてはなりません。記憶されている設定は、それらの設定に準拠しているクライアントがサーバーの現在の設定に違反しない場合に互換性があります。
A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. The server MUST include all settings that differ from their default values. If a server accepts 0-RTT but then sends settings that are not compatible with the previously specified settings, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. If a server accepts 0-RTT but then sends a SETTINGS frame that omits a setting value that the client understands (apart from reserved setting identifiers) that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_SETTINGS_ERROR.
サーバーは0-RTTを受け入れ、その後、設定フレームに異なる設定を提供できます。0-RTTデータがサーバーによって受け入れられた場合、その設定フレームは、0-RTTデータを使用してクライアントが違反する可能性のある制限を減らしたり、変更したりしてはなりません。サーバーには、デフォルト値とは異なるすべての設定を含める必要があります。サーバーが0-RTTを受け入れるが、以前に指定された設定と互換性のない設定を送信する場合、これはタイプH3_Settings_Errorの接続エラーとして扱う必要があります。サーバーが0-RTTを受け入れますが、以前に非デフォルト値を持つように以前に指定されていたクライアントが理解している設定値を省略する設定フレームを送信する場合、これはの接続エラーとして扱わなければなりませんタイプH3_Settings_Error。
The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header section from server to client on a request stream.
Push_Promiseフレーム（Type = 0x05）は、リクエストストリームでサーバーからクライアントまでの約束の要求ヘッダーセクションを運ぶために使用されます。
PUSH_PROMISE Frame {
Type (i) = 0x05,
Length (i),
Push ID (i),
Encoded Field Section (..),
}
Figure 8: PUSH_PROMISE Frame
図8：Push_Promiseフレーム
The payload consists of:
ペイロードは次のとおりです。
Push ID: A variable-length integer that identifies the server push operation. A push ID is used in push stream headers (Section 4.6) and CANCEL_PUSH frames.
プッシュID：サーバープッシュ操作を識別する可変長整数。プッシュIDは、プッシュストリームヘッダー（セクション4.6）およびCancel_Pushフレームで使用されます。
Encoded Field Section: QPACK-encoded request header fields for the promised response. See [QPACK] for more details.
エンコードされたフィールドセクション：約束された応答のQPACKエンコード要求ヘッダーフィールド。詳細については、[QPack]を参照してください。
A server MUST NOT use a push ID that is larger than the client has provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat receipt of a PUSH_PROMISE frame that contains a larger push ID than the client has advertised as a connection error of H3_ID_ERROR.
サーバーは、MAX_PUSH_IDフレーム（セクション7.2.7）で提供されているクライアントよりも大きいプッシュIDを使用してはなりません。クライアントは、クライアントがH3_ID_ERRORの接続エラーとして宣伝しているよりも大きなプッシュIDを含むPush_promiseフレームの受信を扱う必要があります。
A server MAY use the same push ID in multiple PUSH_PROMISE frames. If so, the decompressed request header sets MUST contain the same fields in the same order, and both the name and the value in each field MUST be exact matches. Clients SHOULD compare the request header sections for resources promised multiple times. If a client receives a push ID that has already been promised and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match exactly, the client SHOULD associate the pushed content with each stream on which a PUSH_PROMISE frame was received.
サーバーは、複数のpush_promiseフレームで同じプッシュIDを使用できます。その場合、減圧リクエストヘッダーセットには同じ順序で同じフィールドを含める必要があり、各フィールドの名前と値の両方が正確な一致でなければなりません。クライアントは、何度も約束されたリソースについて、リクエストヘッダーセクションを比較する必要があります。クライアントが既に約束されているプッシュIDを受信し、不一致を検出する場合、タイプh3_general_protocol_errorの接続エラーで応答する必要があります。減圧されたフィールドセクションが正確に一致する場合、クライアントはプッシュされたコンテンツをpush_promiseフレームが受信した各ストリームに関連付ける必要があります。
Allowing duplicate references to the same push ID is primarily to reduce duplication caused by concurrent requests. A server SHOULD avoid reusing a push ID over a long period. Clients are likely to consume server push responses and not retain them for reuse over time. Clients that see a PUSH_PROMISE frame that uses a push ID that they have already consumed and discarded are forced to ignore the promise.
同じプッシュIDへの重複参照を許可することは、主に同時リクエストによって引き起こされる重複を減らすことです。サーバーは、長期間にわたってプッシュIDを再利用することを避ける必要があります。クライアントは、サーバープッシュ応答を消費する可能性が高く、時間の経過とともに再利用するためにそれらを保持しない可能性があります。すでに消費して廃棄したプッシュIDを使用するPush_Promiseフレームを表示するクライアントは、約束を無視することを余儀なくされます。
If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
Push_Promiseフレームがコントロールストリームで受信された場合、クライアントはタイプh3_frame_unexpectedの接続エラーで応答する必要があります。
A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the receipt of a PUSH_PROMISE frame as a connection error of type H3_FRAME_UNEXPECTED.
クライアントは、Push_Promiseフレームを送信してはなりません。サーバーは、Push_Promiseフレームの受信をタイプH3_FRAME_UNEXPECTEDの接続エラーとして処理する必要があります。
See Section 4.6 for a description of the overall server push mechanism.
サーバープッシュメカニズム全体の説明については、セクション4.6を参照してください。
The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint to stop accepting new requests or pushes while still finishing processing of previously received requests and pushes. This enables administrative actions, like server maintenance. GOAWAY by itself does not close a connection.
Goawayフレーム（Type = 0x07）は、いずれかのエンドポイントによるHTTP/3接続の優雅なシャットダウンを開始するために使用されます。Goawayを使用すると、エンドポイントは、以前に受信したリクエストとプッシュの処理を終了しながら、新しいリクエストまたはプッシュの受け入れを停止できます。これにより、サーバーのメンテナンスなどの管理アクションが可能になります。Goaway自体は接続を閉じません。
GOAWAY Frame {
Type (i) = 0x07,
Length (i),
Stream ID/Push ID (i),
}
Figure 9: GOAWAY Frame
図9：Goawayフレーム
The GOAWAY frame is always sent on the control stream. In the server-to-client direction, it carries a QUIC stream ID for a client-initiated bidirectional stream encoded as a variable-length integer. A client MUST treat receipt of a GOAWAY frame containing a stream ID of any other type as a connection error of type H3_ID_ERROR.
Goawayフレームは常にコントロールストリームに送信されます。サーバーからクライアントへの方向では、可変長整数としてエンコードされたクライアントが開始する双方向ストリームのQUICストリームIDを運びます。クライアントは、他のタイプのストリームIDを含むGoAwayフレームの受信を、タイプH3_ID_ERRORの接続エラーとして扱う必要があります。
In the client-to-server direction, the GOAWAY frame carries a push ID encoded as a variable-length integer.
クライアントからサーバーへの方向では、goawayフレームには、可変長整数としてエンコードされたプッシュIDが搭載されています。
The GOAWAY frame applies to the entire connection, not a specific stream. A client MUST treat a GOAWAY frame on a stream other than the control stream as a connection error of type H3_FRAME_UNEXPECTED.
Goawayフレームは、特定のストリームではなく、接続全体に適用されます。クライアントは、型h3_frame_unexpectedの接続エラーとして、コントロールストリーム以外のストリーム上のgoawayフレームを扱う必要があります。
See Section 5.2 for more information on the use of the GOAWAY frame.
Goawayフレームの使用の詳細については、セクション5.2を参照してください。
The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the number of server pushes that the server can initiate. This sets the maximum value for a push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames. Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport.
MAX_PUSH_IDフレーム（Type = 0x0D）は、サーバーが開始できるサーバーのプッシュ数を制御するためにクライアントによって使用されます。これにより、サーバーがpush_promiseおよびcancel_pushフレームで使用できるプッシュIDの最大値を設定します。その結果、これにより、QUICトランスポートが維持する制限に加えて、サーバーが開始できるプッシュストリームの数も制限されます。
The MAX_PUSH_ID frame is always sent on the control stream. Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
max_push_idフレームは常にコントロールストリームで送信されます。他のストリームでのMAX_PUSH_IDフレームの受領は、型h3_frame_unexpectedの接続エラーとして扱う必要があります。
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the receipt of a MAX_PUSH_ID frame as a connection error of type H3_FRAME_UNEXPECTED.
サーバーはMAX_PUSH_IDフレームを送信してはなりません。クライアントは、max_push_idフレームの受領をタイプh3_frame_unexpectedの接続エラーとして扱う必要があります。
The maximum push ID is unset when an HTTP/3 connection is created, meaning that a server cannot push until it receives a MAX_PUSH_ID frame. A client that wishes to manage the number of promised server pushes can increase the maximum push ID by sending MAX_PUSH_ID frames as the server fulfills or cancels server pushes.
HTTP/3接続が作成されると、最大プッシュIDが設定されます。つまり、サーバーはMAX_PUSH_IDフレームを受信するまでプッシュできません。約束されたサーバーのプッシュの数を管理したいクライアントは、サーバーがサーバーのプッシュを履行またはキャンセルするときにMAX_PUSH_IDフレームを送信することにより、最大プッシュIDを増やすことができます。
MAX_PUSH_ID Frame {
Type (i) = 0x0d,
Length (i),
Push ID (i),
}
Figure 10: MAX_PUSH_ID Frame
図10：max_push_idフレーム
The MAX_PUSH_ID frame carries a single variable-length integer that identifies the maximum value for a push ID that the server can use; see Section 4.6. A MAX_PUSH_ID frame cannot reduce the maximum push ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than previously received MUST be treated as a connection error of type H3_ID_ERROR.
MAX_PUSH_IDフレームには、サーバーが使用できるプッシュIDの最大値を識別する単一の変数長整数が搭載されています。セクション4.6を参照してください。MAX_PUSH_IDフレームは、最大プッシュIDを減らすことはできません。以前に受け取ったよりも少ない値を含むMAX_PUSH_IDフレームの受領は、タイプH3_ID_ERRORの接続エラーとして扱う必要があります。
Frame types of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (Section 9). These frames have no semantics, and they MAY be sent on any stream where frames are allowed to be sent. This enables their use for application-layer padding. Endpoints MUST NOT consider these frames to have any meaning upon receipt.
nの非陰性整数値の形式0x1f * n 0x21のフレームタイプは、未知のタイプを無視するという要件を行使するために予約されています（セクション9）。これらのフレームにはセマンティクスがなく、フレームを送信することが許可されているストリームで送信される場合があります。これにより、アプリケーション層パディングに使用できます。エンドポイントは、これらのフレームが受領時に意味を持つことを考慮してはなりません。
The payload and length of the frames are selected in any manner the implementation chooses.
フレームのペイロードと長さは、実装が選択するあらゆる方法で選択されます。
Frame types that were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (Section 11.2.1). These frame types MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
対応するHTTP/3フレームがないHTTP/2で使用されたフレームタイプも予約されています（セクション11.2.1）。これらのフレームタイプを送信する必要はなく、領収書はタイプh3_frame_unexpectedの接続エラーとして扱う必要があります。
When a stream cannot be completed successfully, QUIC allows the application to abruptly terminate (reset) that stream and communicate a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to as a "stream error". An HTTP/3 implementation can decide to close a QUIC stream and communicate the type of error. Wire encodings of error codes are defined in Section 8.1. Stream errors are distinct from HTTP status codes that indicate error conditions. Stream errors indicate that the sender did not transfer or consume the full request or response, while HTTP status codes indicate the result of a request that was successfully received.
ストリームを正常に完了できない場合、QUICにより、アプリケーションはそのストリーミングと伝達をそのストリーミングと伝達するアプリケーションを突然終了（リセット）できます。[Quic-Transport]のセクション2.4を参照してください。これは「ストリームエラー」と呼ばれます。HTTP/3実装は、QUICストリームを閉じてエラーの種類を通信することを決定できます。エラーコードのワイヤーエンコーディングは、セクション8.1で定義されています。ストリームエラーは、エラー条件を示すHTTPステータスコードとは異なります。ストリームエラーは、送信者が完全な要求または応答を転送または消費しなかったことを示していますが、HTTPステータスコードは、正常に受信されたリクエストの結果を示しています。
If an entire connection needs to be terminated, QUIC similarly provides mechanisms to communicate a reason; see Section 5.3 of [QUIC-TRANSPORT]. This is referred to as a "connection error". Similar to stream errors, an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from Section 8.1.
接続全体を終了する必要がある場合、QUICも同様に、理由を伝えるメカニズムを提供します。[Quic-Transport]のセクション5.3を参照してください。これは「接続エラー」と呼ばれます。ストリームエラーと同様に、HTTP/3の実装は、QUIC接続を終了し、セクション8.1のエラーコードを使用して理由を通知できます。
Although the reasons for closing streams and connections are called "errors", these actions do not necessarily indicate a problem with the connection or either implementation. For example, a stream can be reset if the requested resource is no longer needed.
ストリームと接続を閉じる理由は「エラー」と呼ばれますが、これらのアクションは、接続または実装のいずれかの問題を必ずしも示しているわけではありません。たとえば、要求されたリソースが不要になった場合、ストリームをリセットできます。
An endpoint MAY choose to treat a stream error as a connection error under certain circumstances, closing the entire connection in response to a condition on a single stream. Implementations need to consider the impact on outstanding requests before making this choice.
エンドポイントは、特定の状況下でストリームエラーを接続エラーとして扱い、単一のストリームの条件に応じて接続全体を閉じることを選択する場合があります。実装は、この選択を行う前に、未解決のリクエストへの影響を考慮する必要があります。
Because new error codes can be defined without negotiation (see Section 9), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code; for example, see Section 4.1.
新しいエラーコードはネゴシエーションなしで定義できるため（セクション9を参照）、予期しないコンテキストでのエラーコードの使用または未知のエラーコードの受領は、H3_NO_ERRORに相当するものとして扱う必要があります。ただし、ストリームを閉じると、エラーコードに関係なく他の効果があります。たとえば、セクション4.1を参照してください。
The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing HTTP/3 connections.
次のエラーコードは、ストリームを突然終了したり、ストリームの読み取りを中止したり、すぐにHTTP/3接続を閉じたりするときに使用するために定義されます。
H3_NO_ERROR (0x0100): No error. This is used when the connection or stream needs to be closed, but there is no error to signal.
H3_NO_ERROR（0x0100）：エラーなし。これは、接続またはストリームを閉じる必要がある場合に使用されますが、信号するエラーはありません。
H3_GENERAL_PROTOCOL_ERROR (0x0101): Peer violated protocol requirements in a way that does not match a more specific error code or endpoint declines to use the more specific error code.
H3_GENERAL_PROTOCOL_ERROR（0x0101）：より具体的なエラーコードまたはエンドポイントの低下と一致しない方法で、ピアに違反したプロトコル要件がより具体的なエラーコードを使用します。
H3_INTERNAL_ERROR (0x0102): An internal error has occurred in the HTTP stack.
H3_INTERNAL_ERROR（0x0102）：HTTPスタックで内部エラーが発生しました。
H3_STREAM_CREATION_ERROR (0x0103): The endpoint detected that its peer created a stream that it will not accept.
h3_stream_creation_error（0x0103）：エンドポイントは、そのピアが受け入れないストリームを作成したことを検出しました。
H3_CLOSED_CRITICAL_STREAM (0x0104): A stream required by the HTTP/3 connection was closed or reset.
h3_closed_critical_stream（0x0104）：http/3接続に必要なストリームが閉じたかリセットされました。
H3_FRAME_UNEXPECTED (0x0105): A frame was received that was not permitted in the current state or on the current stream.
H3_FRAME_UNEXPECTED（0x0105）：現在の状態または現在のストリームで許可されていないフレームが受信されました。
H3_FRAME_ERROR (0x0106): A frame that fails to satisfy layout requirements or with an invalid size was received.
H3_FRAME_ERROR（0x0106）：レイアウト要件を満たすことができない、または無効なサイズを備えたフレームが受信されました。
H3_EXCESSIVE_LOAD (0x0107): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
H3_Excessive_load（0x0107）：エンドポイントは、そのピアが過度の負荷を生成している動作を示していることを検出しました。
H3_ID_ERROR (0x0108): A stream ID or push ID was used incorrectly, such as exceeding a limit, reducing a limit, or being reused.
H3_ID_ERROR（0x0108）：制限を超える、制限の削減、再利用など、ストリームIDまたはプッシュIDが誤って使用されました。
H3_SETTINGS_ERROR (0x0109): An endpoint detected an error in the payload of a SETTINGS frame.
H3_Settings_Error（0x0109）：エンドポイントが設定フレームのペイロードのエラーを検出しました。
H3_MISSING_SETTINGS (0x010a): No SETTINGS frame was received at the beginning of the control stream.
H3_MISSING_SETTINGS（0x010A）：制御ストリームの先頭に設定フレームは受信されませんでした。
H3_REQUEST_REJECTED (0x010b): A server rejected a request without performing any application processing.
H3_Request_Rejected（0x010B）：サーバーは、アプリケーション処理を実行せずにリクエストを拒否しました。
H3_REQUEST_CANCELLED (0x010c): The request or its response (including pushed response) is cancelled.
H3_REQUEST_CANCELLED（0x010C）：リクエストまたはその応答（プッシュされた応答を含む）がキャンセルされます。
H3_REQUEST_INCOMPLETE (0x010d): The client's stream terminated without containing a fully formed request.
H3_REQUEST_INCOMPLETE（0x010D）：完全に形成されたリクエストを含めることなくクライアントのストリームが終了しました。
H3_MESSAGE_ERROR (0x010e): An HTTP message was malformed and cannot be processed.
h3_message_error（0x010e）：HTTPメッセージは奇形で、処理できません。
H3_CONNECT_ERROR (0x010f): The TCP connection established in response to a CONNECT request was reset or abnormally closed.
H3_Connect_Error（0x010F）：接続要求に応じて確立されたTCP接続がリセットまたは異常に閉じられました。
H3_VERSION_FALLBACK (0x0110): The requested operation cannot be served over HTTP/3. The peer should retry over HTTP/1.1.
h3_version_fallback（0x0110）：要求された操作は、http/3で提供することはできません。ピアはHTTP/1.1を介して再試行する必要があります。
Error codes of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (Section 9). Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR.
nの非陰性整数値の形式0x1f * n 0x21のエラーコードは、未知のエラーコードがH3_NO_ERRORに相当するものとして扱われるという要件を行使するために予約されています（セクション9）。実装は、H3_NO_ERRORを送信した場合、ある程度の確率でこの空間からエラーコードを選択する必要があります。
HTTP/3 permits extension of the protocol. Within the limitations described in this section, protocol extensions can be used to provide additional services or alter any aspect of the protocol. Extensions are effective only within the scope of a single HTTP/3 connection.
HTTP/3は、プロトコルの拡張を許可します。このセクションで説明した制限内で、プロトコル拡張を使用して追加のサービスを提供したり、プロトコルのあらゆる側面を変更したりできます。拡張機能は、単一のHTTP/3接続の範囲内でのみ有効です。
This applies to the protocol elements defined in this document. This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields.
これは、このドキュメントで定義されているプロトコル要素に適用されます。これは、新しいメソッド、ステータスコード、またはフィールドの定義など、HTTPを拡張するための既存のオプションに影響しません。
Extensions are permitted to use new frame types (Section 7.2), new settings (Section 7.2.4.1), new error codes (Section 8), or new unidirectional stream types (Section 6.2). Registries are established for managing these extension points: frame types (Section 11.2.1), settings (Section 11.2.2), error codes (Section 11.2.3), and stream types (Section 11.2.4).
拡張機能は、新しいフレームタイプ（セクション7.2）、新しい設定（セクション7.2.4.1）、新しいエラーコード（セクション8）、または新しい単方向ストリームタイプ（セクション6.2）を使用することができます。レジストリは、これらの拡張ポイントを管理するために確立されます：フレームタイプ（セクション11.2.1）、設定（セクション11.2.2）、エラーコード（セクション11.2.3）、およびストリームタイプ（セクション11.2.4）。
Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard data or abort reading on unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error.
実装は、すべての拡張可能なプロトコル要素で不明な値またはサポートされていない値を無視する必要があります。実装は、未知の型またはサポートされていないタイプを持つ一方向のストリームのデータを破棄するか、読み取りを中止する必要があります。これは、これらの拡張ポイントのいずれかが、事前の取り決めや交渉なしに拡張機能によって安全に使用できることを意味します。ただし、既知のフレームタイプが制御ストリームの最初のフレームとしての設定フレームなどの特定の場所にある必要がある場合（セクション6.2.1を参照）、未知のフレームタイプはその要件を満たさず、処理する必要があります。エラーとして。
Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. Coordinating when such a revised layout comes into effect could prove complex. As such, allocating new identifiers for new definitions of existing protocol elements is likely to be more effective.
既存のプロトコルコンポーネントのセマンティクスを変更できる拡張機能は、使用する前にネゴシエートする必要があります。たとえば、ヘッダーフレームのレイアウトを変更する拡張機能は、ピアがこれが許容できるという正の信号を与えるまで使用できません。そのような改訂されたレイアウトが発効したときに調整することは、複雑であることが証明される可能性があります。そのため、既存のプロトコル要素の新しい定義に新しい識別子を割り当てることがより効果的である可能性があります。
This document does not mandate a specific method for negotiating the use of an extension, but it notes that a setting (Section 7.2.4.1) could be used for that purpose. If both peers set a value that indicates willingness to use the extension, then the extension can be used. If a setting is used for extension negotiation, the default value MUST be defined in such a fashion that the extension is disabled if the setting is omitted.
このドキュメントは、拡張機能の使用を交渉するための特定の方法を義務付けていませんが、その目的に設定（セクション7.2.4.1）を使用できることに注意してください。両方のピアが拡張機能を使用する意欲を示す値を設定する場合、拡張機能を使用できます。設定が拡張交渉に使用される場合、デフォルト値は、設定が省略されている場合に拡張機能が無効になるような方法で定義する必要があります。
The security considerations of HTTP/3 should be comparable to those of HTTP/2 with TLS. However, many of the considerations from Section 10 of [HTTP/2] apply to [QUIC-TRANSPORT] and are discussed in that document.
HTTP/3のセキュリティ上の考慮事項は、TLSを使用してHTTP/2のセキュリティに関する考慮事項に匹敵する必要があります。ただし、[http/2]のセクション10からの考慮事項の多くは、[quic-transport]に適用され、その文書で説明されています。
HTTP/3 relies on the HTTP definition of authority. The security considerations of establishing authority are discussed in Section 17.1 of [HTTP].
HTTP/3は、権限のHTTP定義に依存しています。権限の確立に関するセキュリティ上の考慮事項は、[HTTP]のセクション17.1で説明されています。
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. This ensures that endpoints have strong assurances that peers are using the same protocol.
TLSおよびQUICハンドシェイクでALPNを使用すると、アプリケーションレイヤーバイトが処理される前にターゲットアプリケーションプロトコルが確立されます。これにより、エンドポイントには、ピアが同じプロトコルを使用しているという強い保証が保証されます。
This does not guarantee protection from all cross-protocol attacks. Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports.
これは、すべてのクロスプロトコル攻撃からの保護を保証するものではありません。[Quic-Transport]のセクション21.5では、認証されたトランスポートを使用していないエンドポイントに対してRequest Forgeryを実行するために、QUICパケットのプレーンテキストを使用できるいくつかの方法について説明します。
The HTTP/3 field encoding allows the expression of names that are not valid field names in the syntax used by HTTP (Section 5.1 of [HTTP]). Requests or responses containing invalid field names MUST be treated as malformed. Therefore, an intermediary cannot translate an HTTP/3 request or response containing an invalid field name into an HTTP/1.1 message.
HTTP/3フィールドエンコードは、HTTP（[HTTP]のセクション5.1）で使用されている構文で有効なフィールド名ではない名前の表現を可能にします。無効なフィールド名を含むリクエストまたは応答は、奇形として扱う必要があります。したがって、仲介者は、無効なフィールド名を含むHTTP/3要求または応答をHTTP/1.1メッセージに変換することはできません。
Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a field value MUST be treated as malformed. Valid characters are defined by the "field-content" ABNF rule in Section 5.5 of [HTTP].
同様に、HTTP/3は、無効なフィールド値を輸送できます。エンコードできるほとんどの値はフィールドの解析を変更しませんが、キャリッジリターン（ASCII 0x0D）、ラインフィード（ASCII 0x0A）、およびnull文字（ASCII 0x00）は、攻撃者がverbatimに翻訳されている場合、攻撃者によって搾取される場合があります。フィールド値で許可されていない文字を含むリクエストまたは応答は、奇形として扱わなければなりません。有効な文字は、[HTTP]のセクション5.5の「フィールドコンテンツ」ABNFルールによって定義されます。
Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame.
プッシュされた応答には、クライアントからの明示的な要求がありません。リクエストは、Push_Promiseフレームのサーバーによって提供されます。
Caching responses that are pushed is possible based on the guidance provided by the origin server in the Cache-Control header field. However, this can cause issues if a single server hosts more than one tenant. For example, a server might offer multiple users each a small portion of its URI space.
プッシュされるキャッシュ応答は、キャッシュコントロールヘッダーフィールドでOrigin Serverが提供するガイダンスに基づいて可能です。ただし、単一のサーバーが複数のテナントをホストしている場合、これは問題を引き起こす可能性があります。たとえば、サーバーは、それぞれそれぞれURIスペースのごく一部を複数のユーザーに提供する場合があります。
Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation that would be served out of cache, overriding the actual representation that the authoritative tenant provides.
複数のテナントが同じサーバーでスペースを共有する場合、そのサーバーは、テナントが権限を持たないリソースの表現をプッシュできないことを確認する必要があります。これを実施しないと、テナントがキャッシュから提供される表現を提供し、権威あるテナントが提供する実際の表現を無効にすることができます。
Clients are required to reject pushed responses for which an origin server is not authoritative; see Section 4.6.
クライアントは、Origin Serverが信頼できるものではないプッシュされた応答を拒否する必要があります。セクション4.6を参照してください。
An HTTP/3 connection can demand a greater commitment of resources to operate than an HTTP/1.1 or HTTP/2 connection. The use of field compression and flow control depend on a commitment of resources for storing a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded.
HTTP/3接続は、HTTP/1.1またはHTTP/2接続よりも、動作するためのリソースのより大きなコミットメントを要求する場合があります。フィールド圧縮とフロー制御の使用は、より多くの状態を保存するためのリソースのコミットメントに依存します。これらの機能の設定により、これらの機能のメモリコミットメントが厳密に制限されることが保証されます。
The number of PUSH_PROMISE frames is constrained in a similar fashion. A client that accepts server push SHOULD limit the number of push IDs it issues at a time.
push_promiseフレームの数は、同様の方法で制約されます。サーバーのプッシュを受け入れるクライアントは、一度に発行するプッシュIDの数を制限する必要があります。
Processing capacity cannot be guarded as effectively as state capacity.
処理能力は、状態能力ほど効果的に保護することはできません。
The ability to send undefined protocol elements that the peer is required to ignore can be abused to cause a peer to expend additional processing time. This might be done by setting multiple undefined SETTINGS parameters, unknown frame types, or unknown stream types. Note, however, that some uses are entirely legitimate, such as optional-to-understand extensions and padding to increase resistance to traffic analysis.
ピアが無視する必要がある未定義のプロトコル要素を送信する機能は、ピアが追加の処理時間を消費するために虐待される可能性があります。これは、複数の未定義の設定パラメーター、不明なフレームタイプ、または未知のストリームタイプを設定することによって行われる場合があります。ただし、交通分析に対する抵抗を高めるために、オプションから理解までの拡張機能やパディングなど、一部の用途は完全に合法であることに注意してください。
Compression of field sections also offers some opportunities to waste processing resources; see Section 7 of [QPACK] for more details on potential abuses.
フィールドセクションの圧縮は、加工リソースを無駄にする機会も提供します。潜在的な虐待の詳細については、[QPACK]のセクション7を参照してください。
All these features -- i.e., server push, unknown protocol elements, field compression -- have legitimate uses. These features become a burden only when they are used unnecessarily or to excess.
これらすべての機能（つまり、サーバープッシュ、未知のプロトコル要素、フィールド圧縮）には正当な用途があります。これらの機能は、不必要に使用される場合、または過剰に使用される場合にのみ負担になります。
An endpoint that does not monitor such behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error of type H3_EXCESSIVE_LOAD, but false positives will result in disrupting valid connections and requests.
そのような動作を監視しないエンドポイントは、サービス拒否攻撃のリスクにさらされます。実装は、これらの機能の使用を追跡し、それらの使用に制限を設定する必要があります。エンドポイントは、タイプh3_excessive_loadの接続エラーとして疑わしいアクティビティを扱う可能性がありますが、誤検知は有効な接続と要求を破壊します。
A large field section (Section 4.1) can cause an implementation to commit a large amount of state. Header fields that are critical for routing can appear toward the end of a header section, which prevents streaming of the header section to its ultimate destination. This ordering and other reasons, such as ensuring cache correctness, mean that an endpoint likely needs to buffer the entire header section. Since there is no hard limit to the size of a field section, some endpoints could be forced to commit a large amount of available memory for header fields.
大規模なフィールドセクション（セクション4.1）により、実装が大量の状態をコミットする可能性があります。ルーティングに重要なヘッダーフィールドは、ヘッダーセクションの終わりに向かって表示され、ヘッダーセクションの最終目的地へのストリーミングを防ぎます。キャッシュの正確性を確保するなど、この順序やその他の理由は、エンドポイントがヘッダーセクション全体をバッファリングする必要がある可能性が高いことを意味します。フィールドセクションのサイズに厳しい制限がないため、一部のエンドポイントは、ヘッダーフィールドに大量の利用可能なメモリをコミットすることを余儀なくされる可能性があります。
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (Section 4.2.2) setting to advise peers of limits that might apply on the size of field sections. This setting is only advisory, so endpoints MAY choose to send field sections that exceed this limit and risk having the request or response being treated as malformed. This setting is specific to an HTTP/3 connection, so any request or response could encounter a hop with a lower, unknown limit. An intermediary can attempt to avoid this problem by passing on values presented by different peers, but they are not obligated to do so.
エンドポイントは、settings_max_field_section_size（セクション4.2.2）設定を使用して、フィールドセクションのサイズに適用される可能性のある制限のピアに助言することができます。この設定はアドバイザリーのみであるため、エンドポイントは、この制限を超えるフィールドセクションを送信することを選択し、要求または応答が奇形として扱われているリスクがあるリスクがあります。この設定はHTTP/3接続に固有であるため、リクエストまたは応答は、より低い、未知の制限でホップに遭遇する可能性があります。仲介者は、異なるピアによって提示された価値を渡すことでこの問題を回避しようとすることができますが、そうする義務はありません。
A server that receives a larger field section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code ([RFC6585]). A client can discard responses that it cannot process.
処理するよりも大きなフィールドセクションを受信するサーバーは、HTTP 431（ヘッダーフィールドが大きすぎる）ステータスコード（[RFC6585]）を送信できます。クライアントは、処理できない応答を破棄できます。
The CONNECT method can be used to create disproportionate load on a proxy, since stream creation is relatively inexpensive when compared to the creation and maintenance of a TCP connection. Therefore, a proxy that supports CONNECT might be more conservative in the number of simultaneous requests it accepts.
Connectメソッドは、TCP接続の作成とメンテナンスと比較するとストリームの作成が比較的安価であるため、プロキシに不均衡な負荷を作成するために使用できます。したがって、Connectをサポートするプロキシは、受け入れる同時リクエストの数においてより保守的かもしれません。
A proxy might also maintain some resources for a TCP connection beyond the closing of the stream that carries the CONNECT request, since the outgoing TCP connection remains in the TIME_WAIT state. To account for this, a proxy might delay increasing the QUIC stream limits for some time after a TCP connection terminates.
Proxyは、発信TCP接続がTime_Wait状態に残っているため、Connect Requestを運ぶストリームの閉鎖を超えてTCP接続のリソースを維持する場合があります。これを説明するために、プロキシは、TCP接続が終了した後、しばらくの間、QUICストリーム制限の増加を遅らせる可能性があります。
Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/3 enables compression of fields (Section 4.2); the following concerns also apply to the use of HTTP compressed content-codings; see Section 8.4.1 of [HTTP].
圧縮により、攻撃者は攻撃者制御下のデータと同じコンテキストで圧縮された場合、秘密データを回復することができます。HTTP/3は、フィールドの圧縮を有効にします（セクション4.2）。以下の懸念は、HTTP圧縮コンテンツコーディングの使用にも適用されます。[http]のセクション8.4.1を参照してください。
There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., [BREACH]). The attacker induces multiple requests containing varying plaintext, observing the length of the resulting ciphertext in each, which reveals a shorter length when a guess about the secret is correct.
Webの特性を活用する圧縮に対する実証可能な攻撃があります（例：[違反]）。攻撃者は、さまざまなプレーンテキストを含む複数のリクエストを誘導し、それぞれに結果の暗号文の長さを観察します。
Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression contexts are used for each source of data. Compression MUST NOT be used if the source of data cannot be reliably determined.
安全なチャネルで通信する実装は、データの各ソースに個別の圧縮コンテキストが使用されない限り、機密および攻撃者制御データの両方を含むコンテンツを圧縮してはなりません。データのソースを確実に決定できない場合、圧縮を使用しないでください。
Further considerations regarding the compression of field sections are described in [QPACK].
フィールドセクションの圧縮に関するさらなる考慮事項については、[QPack]で説明されています。
Padding can be used to obscure the exact size of frame content and is provided to mitigate specific attacks within HTTP, for example, attacks where compressed content includes both attacker-controlled plaintext and secret data (e.g., [BREACH]).
パディングは、フレームコンテンツの正確なサイズを不明瞭にするために使用でき、HTTP内の特定の攻撃を緩和するために提供されます。たとえば、圧縮コンテンツには攻撃者制御されたプレーンテキストと秘密データの両方が含まれる攻撃（例：[違反]）。
Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in Sections 7.2.8 and 6.2.3. These methods of padding produce different results in terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation might control padding.
HTTP/2が他のフレームのパディングフレームとパディングフィールドを使用して交通分析により耐性を高めることができます。HTTP/3は、輸送層のパディングに依存するか、セクション7.2.8および6.2で説明されているフレームとストリームの種類を採用できます。.3。これらのパディング方法は、パディングの粒度、保護されている情報に関連してパディングがどのように配置されているか、パケットの損失の場合にパディングが適用されるかどうか、および実装がパディングを制御する方法に関して、さまざまな結果をもたらします。
Reserved stream types can be used to give the appearance of sending traffic even when the connection is idle. Because HTTP traffic often occurs in bursts, apparent traffic can be used to obscure the timing or duration of such bursts, even to the point of appearing to send a constant stream of data. However, as such traffic is still flow controlled by the receiver, a failure to promptly drain such streams and provide additional flow-control credit can limit the sender's ability to send real traffic.
予約済みのストリームタイプを使用して、接続がアイドル状態の場合でもトラフィックを送信するように見えます。HTTPトラフィックはバーストでしばしば発生するため、見かけのトラフィックを使用して、そのようなバーストのタイミングまたは期間を曖昧にすることができます。ただし、そのようなトラフィックは依然としてレシーバーによって制御されているため、そのようなストリームを迅速に排出し、追加のフロー制御クレジットを提供できないと、実際のトラフィックを送信する能力が制限されます。
To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure.
圧縮、無効化、または制限に依存する攻撃を緩和することは、対策としてパディングするよりも望ましい場合があります。
Use of padding can result in less protection than might seem immediately obvious. Redundant padding could even be counterproductive. At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe. Incorrectly implemented padding schemes can be easily defeated. In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext.
パディングを使用すると、すぐに明らかに思えるよりも保護が少なくなる可能性があります。冗長なパディングは逆効果になる可能性があります。せいぜい、パディングは、攻撃者が観察しなければならないフレームの数を増やすことにより、攻撃者が長さの情報を推測することをより困難にするだけです。誤って実装されたパディングスキームは簡単に敗北する可能性があります。特に、予測可能な分布を備えたランダム化されたパディングは、ほとんど保護を提供しません。同様に、ペイロードサイズが固定サイズの境界を越えて情報を固定サイズにパディングすると、ペイロードが情報を公開します。これは、攻撃者がプレーンテキストを制御できる場合に可能です。
Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable-length integers. This could pose a security risk to an incautious implementer. An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains.
いくつかのプロトコル要素には、通常、可変長整数を含む明示的な長さを持つフレームの形で、ネストされた長さ要素が含まれています。これは、矛盾した実装者にセキュリティリスクをもたらす可能性があります。実装では、フレームの長さが含まれるフィールドの長さと正確に一致するようにする必要があります。
The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when using HTTP/3 with 0-RTT. When applying [HTTP-REPLAY] to HTTP/3, references to the TLS layer refer to the handshake performed within QUIC, while all references to application data refer to the contents of streams.
HTTP/3で0-RTTを使用すると、リプレイ攻撃への露出が生じます。[http-replay]のアンチレプレイ緩和は、0-RTTでHTTP/3を使用する場合は適用する必要があります。[http-replay]をHTTP/3に適用する場合、TLSレイヤーへの参照は、QUIC内で実行されたハンドシェイクを指し、アプリケーションデータへのすべての参照はストリームの内容を参照します。
Certain HTTP implementations use the client address for logging or access-control purposes. Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change.
特定のHTTP実装は、ロギングまたはアクセス制御の目的でクライアントアドレスを使用します。接続中にQUICクライアントのアドレスが変更される可能性があるため（および将来のバージョンは複数のアドレスの同時使用をサポートする可能性があるため）、このような実装は、クライアントの現在のアドレスを積極的に取得するか、元のアドレスが変更される可能性があることを明示的に受け入れる必要があります。。
Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.
HTTP/3のいくつかの特性は、オブザーバーに、単一のクライアントまたはサーバーのアクションを時間の経過とともに相関させる機会を提供します。これらには、設定の価値、刺激に対する反応のタイミング、および設定によって制御される機能の取り扱いが含まれます。
As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client.
これらが動作の観察可能な違いを作成する限り、それらは特定のクライアントをフィンガープリントするための基礎として使用できます。
HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site. Reusing connections for different origins allows for correlation of activity across those origins.
単一のQUIC接続を使用するHTTP/3の好みにより、サイトでのユーザーのアクティビティの相関関係が可能になります。さまざまな起源の接続を再利用することで、それらの起源にわたる活動の相関が可能になります。
Several features of QUIC solicit immediate responses and can be used by an endpoint to measure latency to their peer; this might have privacy implications in certain scenarios.
QUICのいくつかの機能は即時の応答を求められ、エンドポイントでピアへの遅延を測定するために使用できます。これは、特定のシナリオでプライバシーの影響を与える可能性があります。
This document registers a new ALPN protocol ID (Section 11.1) and creates new registries that manage the assignment of code points in HTTP/3.
このドキュメントは、新しいALPNプロトコルID（セクション11.1）を登録し、HTTP/3のコードポイントの割り当てを管理する新しいレジストリを作成します。
This document creates a new registration for the identification of HTTP/3 in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301].
このドキュメントでは、[RFC7301]で確立された「TLSアプリケーション層プロトコル交渉（ALPN）プロトコルIDS」レジストリでHTTP/3を識別するための新しい登録を作成します。
The "h3" string identifies HTTP/3:
「H3」文字列はHTTP/3を識別します。
Protocol: HTTP/3
プロトコル：HTTP/3
Identification Sequence: 0x68 0x33 ("h3")
識別シーケンス：0x68 0x33（ "H3"）
Specification: This document
仕様：このドキュメント
New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of [QUIC-TRANSPORT]. These registries all include the common set of fields listed in Section 22.1.1 of [QUIC-TRANSPORT]. These registries are collected under the "Hypertext Transfer Protocol version 3 (HTTP/3)" heading.
このドキュメントで作成された新しいレジストリは、[Quic-Transport]のセクション22.1で文書化されたQUIC登録ポリシーの下で動作します。これらのレジストリにはすべて、[QUIC-Transport]のセクション22.1.1にリストされているフィールドの共通セットが含まれています。これらのレジストリは、「HyperText Transfer Protocolバージョン3（HTTP/3）」という見出しの下で収集されます。
The initial allocations in these registries are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org).
これらのレジストリの初期割り当てにはすべて永続的なステータスが割り当てられており、IETFの変更コントローラーとHTTPワーキンググループ（IETF-HTTP-wg@w3.org）の連絡先がリストされています。
This document establishes a registry for HTTP/3 frame type codes. The "HTTP/3 Frame Types" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
このドキュメントは、HTTP/3フレームタイプコードのレジストリを確立します。「HTTP/3フレームタイプ」レジストリは、62ビットスペースを管理します。このレジストリは、QUICレジストリポリシーに従います。セクション11.2を参照してください。このレジストリの永続的な登録は、0x00から0x3Fの間の値（16進数、包括的）の間の値を除き、標準アクションまたはIESG承認を使用して割り当てられている[16進数、包括的）を除きます。RFC8126]。
While this registry is separate from the "HTTP/2 Frame Type" registry defined in [HTTP/2], it is preferable that the assignments parallel each other where the code spaces overlap. If an entry is present in only one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. Expert reviewers MAY reject unrelated registrations that would conflict with the same value in the corresponding registry.
このレジストリは[http/2]で定義されている「http/2フレームタイプ」レジストリとは分離されていますが、コードスペースの場合、割り当てが相互に並行することが望ましいです。エントリが1つのレジストリのみに存在する場合、対応する値を無関係な操作に割り当てることを避けるためにあらゆる努力をする必要があります。専門家のレビュアーは、対応するレジストリで同じ値と競合する無関係な登録を拒否する場合があります。
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following field:
セクション11.2で説明されている共通フィールドに加えて、このレジストリの永続的な登録には、次のフィールドを含める必要があります。
Frame Type: A name or label for the frame type.
フレームタイプ：フレームタイプの名前またはラベル。
Specifications of frame types MUST include a description of the frame layout and its semantics, including any parts of the frame that are conditionally present.
フレームタイプの仕様には、フレームレイアウトの説明と、条件付きで存在するフレームの部分を含むそのセマンティクスを含める必要があります。
The entries in Table 2 are registered by this document.
表2のエントリは、このドキュメントで登録されています。
+==============+=======+===============+
| Frame Type | Value | Specification |
+==============+=======+===============+
| DATA | 0x00 | Section 7.2.1 |
+--------------+-------+---------------+
| HEADERS | 0x01 | Section 7.2.2 |
+--------------+-------+---------------+
| Reserved | 0x02 | This document |
+--------------+-------+---------------+
| CANCEL_PUSH | 0x03 | Section 7.2.3 |
+--------------+-------+---------------+
| SETTINGS | 0x04 | Section 7.2.4 |
+--------------+-------+---------------+
| PUSH_PROMISE | 0x05 | Section 7.2.5 |
+--------------+-------+---------------+
| Reserved | 0x06 | This document |
+--------------+-------+---------------+
| GOAWAY | 0x07 | Section 7.2.6 |
+--------------+-------+---------------+
| Reserved | 0x08 | This document |
+--------------+-------+---------------+
| Reserved | 0x09 | This document |
+--------------+-------+---------------+
| MAX_PUSH_ID | 0x0d | Section 7.2.7 |
+--------------+-------+---------------+
Table 2: Initial HTTP/3 Frame Types
表2：初期HTTP/3フレームタイプ
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
nの非陰性整数値の形式0x1f * n 0x21の各コード（つまり、0x21、0x40、...、0x3ffffffffffffeから）はIANAによって割り当てられてはならず、割り当てられた値のリストに表示されてはなりません。
This document establishes a registry for HTTP/3 settings. The "HTTP/3 Settings" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
このドキュメントは、HTTP/3設定のレジストリを確立します。「HTTP/3設定」レジストリは、62ビットスペースを管理します。このレジストリは、QUICレジストリポリシーに従います。セクション11.2を参照してください。このレジストリの永続的な登録は、0x00から0x3Fの間の値（16進数、包括的）の間の値を除き、標準アクションまたはIESG承認を使用して割り当てられている[16進数、包括的）を除きます。RFC8126]。
While this registry is separate from the "HTTP/2 Settings" registry defined in [HTTP/2], it is preferable that the assignments parallel each other. If an entry is present in only one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. Expert reviewers MAY reject unrelated registrations that would conflict with the same value in the corresponding registry.
このレジストリは[http/2]で定義されている「http/2設定」レジストリとは分離されていますが、割り当てが相互に並行することが望ましいです。エントリが1つのレジストリのみに存在する場合、対応する値を無関係な操作に割り当てることを避けるためにあらゆる努力をする必要があります。専門家のレビュアーは、対応するレジストリで同じ値と競合する無関係な登録を拒否する場合があります。
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following fields:
セクション11.2で説明されている共通フィールドに加えて、このレジストリの永続的な登録には、次のフィールドを含める必要があります。
Setting Name: A symbolic name for the setting. Specifying a setting name is optional.
設定名：設定のシンボリック名。設定名を指定することはオプションです。
Default: The value of the setting unless otherwise indicated. A default SHOULD be the most restrictive possible value.
デフォルト：特に示されない限り、設定の値。デフォルトは、最も制限的な可能な値である必要があります。
The entries in Table 3 are registered by this document.
表3のエントリは、このドキュメントで登録されています。
+========================+=======+=================+===========+
| Setting Name | Value | Specification | Default |
+========================+=======+=================+===========+
| Reserved | 0x00 | This document | N/A |
+------------------------+-------+-----------------+-----------+
| Reserved | 0x02 | This document | N/A |
+------------------------+-------+-----------------+-----------+
| Reserved | 0x03 | This document | N/A |
+------------------------+-------+-----------------+-----------+
| Reserved | 0x04 | This document | N/A |
+------------------------+-------+-----------------+-----------+
| Reserved | 0x05 | This document | N/A |
+------------------------+-------+-----------------+-----------+
| MAX_FIELD_SECTION_SIZE | 0x06 | Section 7.2.4.1 | Unlimited |
+------------------------+-------+-----------------+-----------+
Table 3: Initial HTTP/3 Settings
表3：初期HTTP/3設定
For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix.
フォーマットの理由で、「settings_」プレフィックスを削除することにより、名前を省略できます。
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
nの非陰性整数値の形式0x1f * n 0x21の各コード（つまり、0x21、0x40、...、0x3ffffffffffffeから）はIANAによって割り当てられてはならず、割り当てられた値のリストに表示されてはなりません。
This document establishes a registry for HTTP/3 error codes. The "HTTP/3 Error Codes" registry manages a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
このドキュメントは、HTTP/3エラーコードのレジストリを確立します。「HTTP/3エラーコード」レジストリは、62ビットスペースを管理します。このレジストリは、QUICレジストリポリシーに従います。セクション11.2を参照してください。このレジストリの永続的な登録は、0x00から0x3Fの間の値（16進数、包括的）の間の値を除き、標準アクションまたはIESG承認を使用して割り当てられている[16進数、包括的）を除きます。RFC8126]。
Registrations for error codes are required to include a description of the error code. An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated. Use of values that are registered in the "HTTP/2 Error Code" registry is discouraged, and expert reviewers MAY reject such registrations.
エラーコードの登録は、エラーコードの説明を含める必要があります。専門家のレビューアは、既存のエラーコードとの複製の可能性について新しい登録を調べることをお勧めします。既存の登録の使用は奨励されますが、義務付けられていません。「HTTP/2エラーコード」レジストリに登録されている値の使用は推奨されず、専門家のレビュアーはそのような登録を拒否する場合があります。
In addition to common fields as described in Section 11.2, this registry includes two additional fields. Permanent registrations in this registry MUST include the following field:
セクション11.2で説明されている共通フィールドに加えて、このレジストリには2つの追加フィールドが含まれています。このレジストリの永続的な登録には、次のフィールドを含める必要があります。
Name: A name for the error code.
名前：エラーコードの名前。
Description: A brief description of the error code semantics.
説明：エラーコードセマンティクスの簡単な説明。
The entries in Table 4 are registered by this document. These error codes were selected from the range that operates on a Specification Required policy to avoid collisions with HTTP/2 error codes.
表4のエントリは、このドキュメントで登録されています。これらのエラーコードは、HTTP/2エラーコードとの衝突を回避するために、仕様が必要なポリシーで動作する範囲から選択されました。
+===========================+========+==============+===============+
| Name | Value | Description | Specification |
+===========================+========+==============+===============+
| H3_NO_ERROR | 0x0100 | No error | Section 8.1 |
+---------------------------+--------+--------------+---------------+
| H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 |
| | | protocol | |
| | | error | |
+---------------------------+--------+--------------+---------------+
| H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 |
| | | error | |
+---------------------------+--------+--------------+---------------+
| H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 |
| | | creation | |
| | | error | |
+---------------------------+--------+--------------+---------------+
| H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 |
| | | stream was | |
| | | closed | |
+---------------------------+--------+--------------+---------------+
| H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 |
| | | permitted | |
| | | in the | |
| | | current | |
| | | state | |
+---------------------------+--------+--------------+---------------+
| H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 |
| | | violated | |
| | | layout or | |
| | | size rules | |
+---------------------------+--------+--------------+---------------+
| H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 |
| | | generating | |
| | | excessive | |
| | | load | |
+---------------------------+--------+--------------+---------------+
| H3_ID_ERROR | 0x0108 | An | Section 8.1 |
| | | identifier | |
| | | was used | |
| | | incorrectly | |
+---------------------------+--------+--------------+---------------+
| H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 |
| | | frame | |
| | | contained | |
| | | invalid | |
| | | values | |
+---------------------------+--------+--------------+---------------+
| H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 |
| | | frame | |
| | | received | |
+---------------------------+--------+--------------+---------------+
| H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 |
| | | processed | |
+---------------------------+--------+--------------+---------------+
| H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 |
| | | longer | |
| | | needed | |
+---------------------------+--------+--------------+---------------+
| H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 |
| | | terminated | |
| | | early | |
+---------------------------+--------+--------------+---------------+
| H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 |
| | | message | |
+---------------------------+--------+--------------+---------------+
| H3_CONNECT_ERROR | 0x010f | TCP reset | Section 8.1 |
| | | or error on | |
| | | CONNECT | |
| | | request | |
+---------------------------+--------+--------------+---------------+
| H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 |
| | | HTTP/1.1 | |
+---------------------------+--------+--------------+---------------+
Table 4: Initial HTTP/3 Error Codes
表4：初期HTTP/3エラーコード
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
nの非陰性整数値の形式0x1f * n 0x21の各コード（つまり、0x21、0x40、...、0x3ffffffffffffeから）はIANAによって割り当てられてはならず、割り当てられた値のリストに表示されてはなりません。
This document establishes a registry for HTTP/3 unidirectional stream types. The "HTTP/3 Stream Types" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
このドキュメントは、HTTP/3単方向ストリームタイプのレジストリを確立します。「HTTP/3ストリームタイプ」レジストリは、62ビットスペースを管理します。このレジストリは、QUICレジストリポリシーに従います。セクション11.2を参照してください。このレジストリの永続的な登録は、0x00から0x3Fの間の値（16進数、包括的）の間の値を除き、標準アクションまたはIESG承認を使用して割り当てられている[16進数、包括的）を除きます。RFC8126]。
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following fields:
セクション11.2で説明されている共通フィールドに加えて、このレジストリの永続的な登録には、次のフィールドを含める必要があります。
Stream Type: A name or label for the stream type.
ストリームタイプ：ストリームタイプの名前またはラベル。
Sender: Which endpoint on an HTTP/3 connection may initiate a stream of this type. Values are "Client", "Server", or "Both".
送信者：HTTP/3接続のエンドポイントは、このタイプのストリームを開始する場合があります。値は「クライアント」、「サーバー」、または「両方」です。
Specifications for permanent registrations MUST include a description of the stream type, including the layout and semantics of the stream contents.
恒久的な登録の仕様には、ストリームコンテンツのレイアウトやセマンティクスなど、ストリームタイプの説明を含める必要があります。
The entries in Table 5 are registered by this document.
表5のエントリは、このドキュメントで登録されています。
+================+=======+===============+========+
| Stream Type | Value | Specification | Sender |
+================+=======+===============+========+
| Control Stream | 0x00 | Section 6.2.1 | Both |
+----------------+-------+---------------+--------+
| Push Stream | 0x01 | Section 4.6 | Server |
+----------------+-------+---------------+--------+
Table 5: Initial Stream Types
表5：初期ストリームタイプ
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
nの非陰性整数値の形式0x1f * n 0x21の各コード（つまり、0x21、0x40、...、0x3ffffffffffffeから）はIANAによって割り当てられてはならず、割り当てられた値のリストに表示されてはなりません。
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[Altsvc] Nottingham、M.、McManus、P。、およびJ. Reschke、「HTTP代替サービス」、RFC 7838、DOI 10.17487/RFC7838、2016年4月、<https://www.rfc-editor.org/info/RFC7838>。
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[Cookies] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487/RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[HTTP] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTPキャッシュ] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "Http Caching"、Std 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.
[HTTP-Replay] Thomson、M.、Nottingham、M.、およびW. Tarreau、「HTTPでの初期データの使用」、RFC 8470、DOI 10.17487/RFC8470、2018年9月、<https：//www.rfc-edtuter。org/info/rfc8470>。
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: Field Compression for HTTP/3", RFC 9204, DOI 10.17487/RFC9204, June 2022, <https://www.rfc-editor.org/info/rfc9204>.
[Qpack] Krasic、C.、Bishop、M.、およびA. Frindell、ed。、「QPack：HTTP/3のフィールド圧縮」、RFC 9204、DOI 10.17487/RFC9204、2022年6月、<https：// www。rfc-editor.org/info/rfc9204>。
[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[Quic-Transport] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J。、「伝送制御プロトコル」、STD 7、RFC 793、DOI 10.17487/RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] EastLake 3rd、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487/RFC6066、2011年1月、<https://www.rfc-editor.org/info/RFC6066>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「輸送層セキュリティ（TLS）アプリケーション層プロトコル交渉拡張」、RFC 7301、DOI 10.17487/RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the CRIME Attack", July 2013, <http://breachattack.com/resources/ BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[違反] Gluck、Y.、Harris、N.、A。Prado、「違反：犯罪攻撃の復活」、2013年7月、<http://breeachatcack.com/resources/ Breach％20-％20SSL、％20GONE％20in％2030％20seconds.pdf>。
[DNS-TERMS] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[DNS-TERMS] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487/RFC8499、2019年1月、<https：//www.rfc-editor。org/info/rfc8499>。
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[HPack] Peon、R。and H. Ruellan、 "HPack：HTTP/2のヘッダー圧縮、RFC 7541、DOI 10.17487/RFC7541、2015年5月、<https://www.rfc-editor.org/info/RFC7541>。
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/1.1] Fielding、R.、ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<<https://www.rfc-editor.org/info/rfc9112>。
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/2] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/info/rfc6585>.
[RFC6585]ノッティンガム、M。およびR.フィールディング、「追加のHTTPステータスコード」、RFC 6585、DOI 10.17487/RFC6585、2012年4月、<https://www.rfc-editor.org/info/rfc6585>
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>.
[RFC8164]ノッティンガム、M。およびM.トムソン、「HTTP/2の日和見的セキュリティ」、RFC 8164、DOI 10.17487/RFC8164、2017年5月<https://www.rfc-editor.org/info/rfc8164>
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[TFO] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487/RFC7413、2014年12月、<https：//www.rfc-editor.org/info/rfc7413>。
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLS] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
Appendix A. Considerations for Transitioning from HTTP/2
付録A. HTTP/2からの移行に関する考慮事項
HTTP/3 is strongly informed by HTTP/2, and it bears many similarities. This section describes the approach taken to design HTTP/3, points out important differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
HTTP/3はHTTP/2によって強く通知されており、多くの類似点があります。このセクションでは、HTTP/3を設計するためのアプローチについて説明し、HTTP/2との重要な違いを指摘し、HTTP/2拡張機能をHTTP/3にマッピングする方法について説明します。
HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 where QUIC differs from TCP, either to take advantage of QUIC features (like streams) or to accommodate important shortcomings (such as a lack of total ordering). While HTTP/3 is similar to HTTP/2 in key aspects, such as the relationship of requests and responses to streams, the details of the HTTP/3 design are substantially different from HTTP/2.
HTTP/3は、HTTP/2との類似性が望ましいが、難しい要件ではないという前提から始まります。HTTP/3は、QUICがQUIC機能（ストリームなど）を利用するか、重要な欠点（総注文不足など）に対応するために、QUICがTCPとは異なるHTTP/2から出発します。HTTP/3は、要求や応答のストリームとの関係など、重要な側面ではHTTP/2に似ていますが、HTTP/3デザインの詳細はHTTP/2とは大きく異なります。
Some important departures are noted in this section.
このセクションでは、いくつかの重要な出発点が記載されています。
HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/2. The same considerations about exhaustion of stream identifier space apply, though the space is significantly larger such that it is likely that other limits in QUIC are reached first, such as the limit on the connection flow-control window.
HTTP/3は、HTTP/2よりも多くのストリーム（2^62-1）の使用を許可します。ストリーム識別子スペースの枯渇に関する同じ考慮事項が適用されますが、スペースは大幅に大きいため、接続フローコントロールウィンドウの制限など、最初にQUICの他の制限に達する可能性があります。
In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC. QUIC considers a stream closed when all data has been received and sent data has been acknowledged by the peer. HTTP/2 considers a stream closed when the frame containing the END_STREAM bit has been committed to the transport. As a result, the stream for an equivalent exchange could remain "active" for a longer period of time. HTTP/3 servers might choose to permit a larger number of concurrent client-initiated bidirectional streams to achieve equivalent concurrency to HTTP/2, depending on the expected usage patterns.
HTTP/2とは対照的に、HTTP/3のストリームの並行性はQUICによって管理されます。QUICは、すべてのデータが受信され、送信されたデータがピアによって認められたときにストリームが閉じられたと見なします。HTTP/2は、END_STREAMビットを含むフレームが輸送にコミットしている場合、ストリームを閉じたと考慮します。その結果、同等の交換のストリームは、より長い期間「アクティブ」のままである可能性があります。HTTP/3サーバーは、予想される使用パターンに応じて、HTTP/2と同等の同時性を実現するために、より多くの同時クライアントが誘導する双方向ストリームを許可することを選択する場合があります。
In HTTP/2, only request and response bodies (the frame payload of DATA frames) are subject to flow control. All HTTP/3 frames are sent on QUIC streams, so all frames on all streams are flow controlled in HTTP/3.
HTTP/2では、リクエストと応答ボディ（データフレームのフレームペイロード）のみがフロー制御の対象となります。すべてのHTTP/3フレームはQUICストリームで送信されるため、すべてのストリームのすべてのフレームはHTTP/3でフロー制御されます。
Due to the presence of other unidirectional stream types, HTTP/3 does not rely exclusively on the number of concurrent unidirectional streams to control the number of concurrent in-flight pushes. Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the number of pushes received from an HTTP/3 server.
他の一方向の河川タイプが存在するため、HTTP/3は、同時の飛行中のプッシュの数を制御するために、同時の単方向ストリームの数だけに依存していません。代わりに、HTTP/3クライアントはMAX_PUSH_IDフレームを使用して、HTTP/3サーバーから受信したプッシュの数を制御します。
Many framing concepts from HTTP/2 can be elided on QUIC, because the transport deals with them. Because frames are already on a stream, they can omit the stream number. Because frames do not block multiplexing (QUIC's multiplexing occurs below this layer), the support for variable-maximum-length packets can be removed. Because stream termination is handled by QUIC, an END_STREAM flag is not required. This permits the removal of the Flags field from the generic frame layout.
HTTP/2の多くのフレーミングの概念は、輸送がそれらを扱っているため、QUICで排除できます。フレームはすでにストリーム上にあるため、ストリーム番号を省略できます。フレームが多重化をブロックしないため（QUICのマルチプレックスはこのレイヤーの下で発生します）、可変マキシム長さのパケットのサポートを削除できます。ストリーム終了はQUICによって処理されるため、END_STREAMフラグは必要ありません。これにより、一般的なフレームレイアウトからフラグフィールドを削除できます。
Frame payloads are largely drawn from [HTTP/2]. However, QUIC includes many features (e.g., flow control) that are also present in HTTP/2. In these cases, the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer used, the frame ID has been reserved in order to maximize portability between HTTP/2 and HTTP/3 implementations. However, even frame types that appear in both mappings do not have identical semantics.
フレームペイロードは、[http/2]から主に描かれています。ただし、QUICには、HTTP/2にも存在する多くの機能（フロー制御など）が含まれます。これらの場合、HTTPマッピングはそれらを再実装しません。その結果、HTTP/3ではいくつかのHTTP/2フレームタイプは必要ありません。HTTP/2定義のフレームが使用されなくなった場合、HTTP/2とHTTP/3の実装の間の移植性を最大化するために、フレームIDが予約されています。ただし、両方のマッピングに表示されるフレームタイプであっても、同一のセマンティクスはありません。
Many of the differences arise from the fact that HTTP/2 provides an absolute ordering between frames across all streams, while QUIC provides this guarantee on each stream only. As a result, if a frame type makes assumptions that frames from different streams will still be received in the order sent, HTTP/3 will break them.
違いの多くは、HTTP/2がすべてのストリームのフレーム間で絶対的な順序を提供するという事実から生じますが、QUICは各ストリームのみでこの保証を提供します。その結果、フレームタイプが異なるストリームのフレームが送信された注文でまだ受信されると仮定すると、HTTP/3がそれらを破壊します。
Some examples of feature adaptations are described below, as well as general guidance to extension frame implementors converting an HTTP/2 extension to HTTP/3.
機能適応のいくつかの例を以下に説明し、HTTP/2拡張機能をHTTP/3に変換する拡張フレーム実装者への一般的なガイダンスを説明します。
HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority.
HTTP/2は、優先順位フレームと（オプションで）ヘッダーフレームで優先度の割り当てを指定します。HTTP/3は、優先順位を示す手段を提供しません。
Note that, while there is no explicit signaling for priority, this does not mean that prioritization is not important for achieving good performance.
優先順位の明示的なシグナルはありませんが、これは優れたパフォーマンスを達成するために優先順位付けが重要ではないことを意味しないことに注意してください。
HPACK was designed with the assumption of in-order delivery. A sequence of encoded field sections must arrive (and be decoded) at an endpoint in the same order in which they were encoded. This ensures that the dynamic state at the two endpoints remains in sync.
HPACKは、注文の配信を仮定して設計されました。エンコードされたフィールドセクションのシーケンスは、エンコードされたのと同じ順序でエンドポイントに到着（およびデコードされる）必要があります。これにより、2つのエンドポイントの動的状態が同期し続けることが保証されます。
Because this total ordering is not provided by QUIC, HTTP/3 uses a modified version of HPACK, called QPACK. QPACK uses a single unidirectional stream to make all modifications to the dynamic table, ensuring a total order of updates. All frames that contain encoded fields merely reference the table state at a given time without modifying it.
この合計順序はQUICによって提供されていないため、HTTP/3はQPACKと呼ばれるHPACKの変更バージョンを使用します。QPACKは、単一の単方向ストリームを使用して、動的テーブルをすべての変更を行い、更新の合計順序を確保します。エンコードされたフィールドを含むすべてのフレームは、変更せずに特定の時間にテーブル状態を参照するだけです。
[QPACK] provides additional details.
[QPack]は追加の詳細を提供します。
HTTP/2 specifies a stream flow-control mechanism. Although all HTTP/2 frames are delivered on streams, only the DATA frame payload is subject to flow control. QUIC provides flow control for stream data and all HTTP/3 frame types defined in this document are sent on streams. Therefore, all frame headers and payload are subject to flow control.
HTTP/2ストリームフロー制御メカニズムを指定します。すべてのHTTP/2フレームはストリームで配信されますが、データフレームペイロードのみがフロー制御の対象となります。QUICは、ストリームデータのフロー制御を提供し、このドキュメントで定義されているすべてのHTTP/3フレームタイプがストリームで送信されます。したがって、すべてのフレームヘッダーとペイロードはフロー制御の対象となります。
Frame type definitions in HTTP/3 often use the QUIC variable-length integer encoding. In particular, stream IDs use this encoding, which allows for a larger range of possible values than the encoding used in HTTP/2. Some frames in HTTP/3 use an identifier other than a stream ID (e.g., push IDs). Redefinition of the encoding of extension frame types might be necessary if the encoding includes a stream ID.
http/3のフレームタイプ定義は、多くの場合、quic変数長整数エンコードを使用します。特に、ストリームIDはこのエンコードを使用します。これにより、HTTP/2で使用されるエンコードよりも範囲の可能な値が広がります。HTTP/3の一部のフレームは、ストリームID（プッシュIDなど）以外の識別子を使用します。エンコードにストリームIDが含まれている場合、拡張フレームタイプのエンコードの再定義が必要になる場合があります。
Because the Flags field is not present in generic HTTP/3 frames, those frames that depend on the presence of flags need to allocate space for flags as part of their frame payload.
フラグフィールドは汎用HTTP/3フレームには存在しないため、フラグの存在に依存するフレームは、フレームペイロードの一部としてフラグにスペースを割り当てる必要があります。
Other than these issues, frame type HTTP/2 extensions are typically portable to QUIC simply by replacing stream 0 in HTTP/2 with a control stream in HTTP/3. HTTP/3 extensions will not assume ordering, but would not be harmed by ordering, and are expected to be portable to HTTP/2.
これらの問題以外に、フレームタイプのhttp/2拡張機能は、通常、HTTP/2のストリーム0をHTTP/3のコントロールストリームに置き換えるだけで、QUICに移植可能です。HTTP/3拡張機能は注文を想定していませんが、注文によって傷つけられず、HTTP/2に移植可能であると予想されます。
DATA (0x00): Padding is not defined in HTTP/3 frames. See Section 7.2.1.
データ（0x00）：パディングはHTTP/3フレームでは定義されていません。セクション7.2.1を参照してください。
HEADERS (0x01): The PRIORITY region of HEADERS is not defined in HTTP/3 frames. Padding is not defined in HTTP/3 frames. See Section 7.2.2.
ヘッダー（0x01）：ヘッダーの優先領域は、HTTP/3フレームでは定義されていません。パディングはHTTP/3フレームでは定義されていません。セクション7.2.2を参照してください。
PRIORITY (0x02): As described in Appendix A.2.1, HTTP/3 does not provide a means of signaling priority.
優先度（0x02）：付録A.2.1に記載されているように、HTTP/3はシグナリングの優先度の手段を提供しません。
RST_STREAM (0x03): RST_STREAM frames do not exist in HTTP/3, since QUIC provides stream lifecycle management. The same code point is used for the CANCEL_PUSH frame (Section 7.2.3).
RST_STREAM（0x03）：QUICはストリームライフサイクル管理を提供するため、rst_streamフレームはHTTP/3には存在しません。Cancel_Pushフレーム（セクション7.2.3）に同じコードポイントが使用されます。
SETTINGS (0x04): SETTINGS frames are sent only at the beginning of the connection. See Section 7.2.4 and Appendix A.3.
設定（0x04）：設定フレームは、接続の開始時にのみ送信されます。セクション7.2.4および付録A.3を参照してください。
PUSH_PROMISE (0x05): The PUSH_PROMISE frame does not reference a stream; instead, the push stream references the PUSH_PROMISE frame using a push ID. See Section 7.2.5.
push_promise（0x05）：push_promiseフレームはストリームを参照しません。代わりに、プッシュストリームはプッシュIDを使用してPush_Promiseフレームを参照します。セクション7.2.5を参照してください。
PING (0x06): PING frames do not exist in HTTP/3, as QUIC provides equivalent functionality.
ping（0x06）：quicが同等の機能を提供するため、pingフレームはhttp/3には存在しません。
GOAWAY (0x07): GOAWAY does not contain an error code. In the client-to-server direction, it carries a push ID instead of a server-initiated stream ID. See Section 7.2.6.
goaway（0x07）：goawayにはエラーコードが含まれていません。クライアントからサーバーへの方向では、サーバーが開始したストリームIDの代わりにプッシュIDを運びます。セクション7.2.6を参照してください。
WINDOW_UPDATE (0x08): WINDOW_UPDATE frames do not exist in HTTP/3, since QUIC provides flow control.
window_update（0x08）：window_updateフレームは、http/3には存在しません。これは、quicがフロー制御を提供するためです。
CONTINUATION (0x09): CONTINUATION frames do not exist in HTTP/3; instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.
継続（0x09）：継続フレームはhttp/3には存在しません。代わりに、HTTP/2よりも大きなヘッダー/Push_Promiseフレームが許可されています。
Frame types defined by extensions to HTTP/2 need to be separately registered for HTTP/3 if still applicable. The IDs of frames defined in [HTTP/2] have been reserved for simplicity. Note that the frame type space in HTTP/3 is substantially larger (62 bits versus 8 bits), so many HTTP/3 frame types have no equivalent HTTP/2 code points. See Section 11.2.1.
HTTP/2への拡張機能によって定義されたフレームタイプは、まだ適用可能な場合はHTTP/3に個別に登録する必要があります。[http/2]で定義されているフレームのIDは、単純さのために予約されています。HTTP/3のフレームタイプスペースは大幅に大きい（62ビット対8ビット）、HTTP/3フレームの多くのタイプには同等のHTTP/2コードポイントがないことに注意してください。セクション11.2.1を参照してください。
An important difference from HTTP/2 is that settings are sent once, as the first frame of the control stream, and thereafter cannot change. This eliminates many corner cases around synchronization of changes.
HTTP/2との重要な違いは、制御ストリームの最初のフレームとして設定が1回送信され、その後変更できないことです。これにより、変更の同期に関する多くのコーナーケースが排除されます。
Some transport-level options that HTTP/2 specifies via the SETTINGS frame are superseded by QUIC transport parameters in HTTP/3. The HTTP-level setting that is retained in HTTP/3 has the same value as in HTTP/2. The superseded settings are reserved, and their receipt is an error. See Section 7.2.4.1 for discussion of both the retained and reserved values.
HTTP/2が設定フレームを介して指定するいくつかのトランスポートレベルのオプションは、HTTP/3のQUICトランスポートパラメーターに取って代わられます。HTTP/3で保持されるHTTPレベルの設定は、HTTP/2と同じ値を持っています。置き換えられた設定は予約されており、その領収書はエラーです。保持値と予約された値の両方の議論については、セクション7.2.4.1を参照してください。
Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:
以下は、各HTTP/2設定パラメーターのマッピング方法のリストです。
SETTINGS_HEADER_TABLE_SIZE (0x01): See [QPACK].
settings_header_table_size（0x01）：[qpack]を参照してください。
SETTINGS_ENABLE_PUSH (0x02): This is removed in favor of the MAX_PUSH_ID frame, which provides a more granular control over server push. Specifying a setting with the identifier 0x02 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame is an error.
settings_enable_push（0x02）：これは、max_push_idフレームに有利に削除され、サーバープッシュをより詳細に制御できます。HTTP/3設定フレームで識別子0x02（settings_enable_pushパラメーターに対応）で設定を指定することはエラーです。
SETTINGS_MAX_CONCURRENT_STREAMS (0x03): QUIC controls the largest open stream ID as part of its flow-control logic. Specifying a setting with the identifier 0x03 (corresponding to the SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS frame is an error.
settings_max_concurrent_streams（0x03）：quicは、フローコントロールロジックの一部として最大のオープンストリームIDを制御します。HTTP/3設定フレームの識別子0x03（settings_max_concurrent_streamsパラメーターに対応）で設定を指定することはエラーです。
SETTINGS_INITIAL_WINDOW_SIZE (0x04): QUIC requires both stream and connection flow-control window sizes to be specified in the initial transport handshake. Specifying a setting with the identifier 0x04 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE parameter) in the HTTP/3 SETTINGS frame is an error.
settings_initial_window_size（0x04）：quicでは、初期トランスポートハンドシェイクでストリームと接続フローコントロールの両方のウィンドウサイズを指定する必要があります。HTTP/3設定フレームで識別子0x04（settings_initial_window_sizeパラメーターに対応）で設定を指定することはエラーです。
SETTINGS_MAX_FRAME_SIZE (0x05): This setting has no equivalent in HTTP/3. Specifying a setting with the identifier 0x05 (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the HTTP/3 SETTINGS frame is an error.
settings_max_frame_size（0x05）：この設定には、http/3では同等のものがありません。HTTP/3設定フレームで識別子0x05（settings_max_frame_sizeパラメーターに対応）で設定を指定することはエラーです。
SETTINGS_MAX_HEADER_LIST_SIZE (0x06): This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.
settings_max_header_list_size（0x06）：この設定識別子は、settings_max_field_section_sizeに変更されました。
In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. This will often produce a shorter encoding, but can produce a longer encoding for settings that use the full 32-bit space. Settings ported from HTTP/2 might choose to redefine their value to limit it to 30 bits for more efficient encoding or to make use of the 62-bit space if more than 30 bits are required.
HTTP/3では、設定値は、HTTP/2のように固定長32ビットフィールドではなく、可変長さの整数（6、14、30、または62ビット長さ）です。これにより、より短いエンコードが生成されることがよくありますが、完全な32ビットスペースを使用する設定の長いエンコードを生成できます。HTTP/2から移植された設定は、より効率的なエンコードのために30ビットに制限するために値を再定義することを選択する場合、または30ビット以上が必要な場合は62ビットスペースを使用することを選択する場合があります。
Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs of settings defined in [HTTP/2] have been reserved for simplicity. Note that the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See Section 11.2.2.
設定は、HTTP/2およびHTTP/3で個別に定義する必要があります。[http/2]で定義されている設定のIDは、単純さのために予約されています。HTTP/3の設定識別子スペースは大幅に大きい（62ビット対16ビット）、HTTP/3の多くの設定には同等のHTTP/2コードポイントがないことに注意してください。セクション11.2.2を参照してください。
As QUIC streams might arrive out of order, endpoints are advised not to wait for the peers' settings to arrive before responding to other streams. See Section 7.2.4.2.
QUICストリームは順不同で到着する可能性があるため、エンドポイントは、他のストリームに応答する前に、ピアの設定が到着するのを待たないようにすることをお勧めします。セクション7.2.4.2を参照してください。
QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 mean that error codes are not directly portable between versions.
QUICには、HTTP/2が提供する「ストリーム」と「接続」エラーの概念が同じです。ただし、HTTP/2とHTTP/3の違いは、エラーコードがバージョン間で直接ポータブルではないことを意味します。
The HTTP/2 error codes defined in Section 7 of [HTTP/2] logically map to the HTTP/3 error codes as follows:
[http/2]のセクション7で定義されているHTTP/2エラーコードは、次のようにHTTP/3エラーコードに論理的にマッピングされます。
NO_ERROR (0x00): H3_NO_ERROR in Section 8.1.
NO_ERROR（0x00）：セクション8.1のH3_NO_ERROR。
PROTOCOL_ERROR (0x01): This is mapped to H3_GENERAL_PROTOCOL_ERROR except in cases where more specific error codes have been defined. Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and H3_CLOSED_CRITICAL_STREAM defined in Section 8.1.
Protocol_Error（0x01）：これは、より具体的なエラーコードが定義されている場合を除き、H3_general_protocol_errorにマッピングされます。このようなケースには、h3_frame_unexpected、h3_message_error、およびh3_closed_critical_streamがセクション8.1で定義されていることが含まれます。
INTERNAL_ERROR (0x02): H3_INTERNAL_ERROR in Section 8.1.
Internal_Error（0x02）：セクション8.1のH3_INTERNAL_ERROR。
FLOW_CONTROL_ERROR (0x03): Not applicable, since QUIC handles flow control.
flow_control_error（0x03）：quicがフロー制御を処理するため、該当しません。
SETTINGS_TIMEOUT (0x04): Not applicable, since no acknowledgment of SETTINGS is defined.
settings_timeout（0x04）：設定の承認が定義されていないため、該当しません。
STREAM_CLOSED (0x05): Not applicable, since QUIC handles stream management.
stream_closed（0x05）：quicがストリーム管理を処理するため、該当しません。
FRAME_SIZE_ERROR (0x06): H3_FRAME_ERROR error code defined in Section 8.1.
frame_size_error（0x06）：セクション8.1で定義されているH3_frame_errorエラーコード。
REFUSED_STREAM (0x07): H3_REQUEST_REJECTED (in Section 8.1) is used to indicate that a request was not processed. Otherwise, not applicable because QUIC handles stream management.
Refused_stream（0x07）：H3_Request_Rejected（セクション8.1）は、リクエストが処理されていないことを示すために使用されます。それ以外の場合は、QUICがストリーム管理を処理するため、適用されません。
CANCEL (0x08): H3_REQUEST_CANCELLED in Section 8.1.
キャンセル（0x08）：h3_request_cancelledセクション8.1で。
COMPRESSION_ERROR (0x09): Multiple error codes are defined in [QPACK].
Compression_Error（0x09）：複数のエラーコードが[qpack]で定義されています。
CONNECT_ERROR (0x0a): H3_CONNECT_ERROR in Section 8.1.
Connect_Error（0x0a）：セクション8.1のH3_Connect_Error。
ENHANCE_YOUR_CALM (0x0b): H3_EXCESSIVE_LOAD in Section 8.1.
Enhance_your_calm（0x0b）：セクション8.1のH3_Excessive_load。
INADEQUATE_SECURITY (0x0c): Not applicable, since QUIC is assumed to provide sufficient security on all connections.
inadequate_security（0x0c）：すべての接続に十分なセキュリティを提供するとquicが想定されるため、該当しません。
HTTP_1_1_REQUIRED (0x0d): H3_VERSION_FALLBACK in Section 8.1.
http_1_1_required（0x0d）：セクション8.1のh3_version_fallback。
Error codes need to be defined for HTTP/2 and HTTP/3 separately. See Section 11.2.3.
エラーコードは、HTTP/2およびHTTP/3の定義を個別に定義する必要があります。セクション11.2.3を参照してください。
An intermediary that converts between HTTP/2 and HTTP/3 may encounter error conditions from either upstream. It is useful to communicate the occurrence of errors to the downstream, but error codes largely reflect connection-local problems that generally do not make sense to propagate.
HTTP/2とHTTP/3を変換する仲介者は、いずれかの上流からエラー条件に遭遇する可能性があります。エラーの発生をダウンストリームに伝えると便利ですが、エラーコードは、一般的に伝播する意味がない接続ローカルの問題を主に反映しています。
An intermediary that encounters an error from an upstream origin can indicate this by sending an HTTP status code such as 502 (Bad Gateway), which is suitable for a broad class of errors.
上流のオリジンからエラーに遭遇する仲介者は、幅広いクラスのエラーに適した502（Bad Gateway）などのHTTPステータスコードを送信することでこれを示すことができます。
There are some rare cases where it is beneficial to propagate the error by mapping it to the closest matching error type to the receiver. For example, an intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from the origin has a clear signal that the request was not processed and that the request is safe to retry. Propagating this error condition to the client as an HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the action it deems most appropriate. In the reverse direction, the intermediary might deem it beneficial to pass on client request cancellations that are indicated by terminating a stream with H3_REQUEST_CANCELLED; see Section 4.1.1.
エラーをレシーバーに最も近いマッチングエラータイプにマッピングすることにより、エラーを伝播することが有益な場合があります。たとえば、OriginからHTTP/2ストリームエラーを受信した中間監視_STREAMを受け取る中間層には、リクエストが処理されず、リクエストが再試行するのが安全であるという明確な信号があります。このエラー条件をタイプH3_Request_RejededのHTTP/3ストリームエラーとしてクライアントに伝播すると、クライアントが最も適切だと思われるアクションを実行できます。逆方向に、仲介者は、h3_request_cancelledを使用してストリームを終了することによって示されるクライアント要求のキャンセルを渡すことが有益であると考えるかもしれません。セクション4.1.1を参照してください。
Conversion between errors is described in the logical mapping. The error codes are defined in non-overlapping spaces in order to protect against accidental conversion that could result in the use of inappropriate or unknown error codes for the target version. An intermediary is permitted to promote stream errors to connection errors but they should be aware of the cost to the HTTP/3 connection for what might be a temporary or intermittent error.
エラー間の変換は、論理マッピングで説明されています。エラーコードは、ターゲットバージョンに不適切または不明なエラーコードを使用する可能性のある偶発的な変換から保護するために、非重複スペースで定義されます。仲介者は、ストリームエラーを接続エラーに促進することが許可されていますが、一時的または断続的なエラーである可能性のあるHTTP/3接続のコストを認識する必要があります。
Acknowledgments
謝辞
Robbie Shade and Mike Warres were the authors of draft-shade-quic-http2-mapping, a precursor of this document.
Robbie ShadeとMike Warresは、この文書の前駆体であるDraft-Shade-Quic-Http2-Mappingの著者でした。
The IETF QUIC Working Group received an enormous amount of support from many people. Among others, the following people provided substantial contributions to this document:
IETF QUICワーキンググループは、多くの人々から膨大な量のサポートを受けました。とりわけ、次の人々はこの文書に多大な貢献を提供しました。
* Bence Beky * Daan De Meyer * Martin Duke * Roy Fielding * Alan Frindell * Alessandro Ghedini * Nick Harper * Ryan Hamilton * Christian Huitema * Subodh Iyengar * Robin Marx * Patrick McManus * Luca Niccolini * 奥 一穂 (Kazuho Oku) * Lucas Pardue * Roberto Peon * Julian Reschke * Eric Rescorla * Martin Seemann * Ben Schwartz * Ian Swett * Willy Taureau * Martin Thomson * Dmitri Tikhonov * Tatsuhiro Tsujikawa
* Bence Beky * Daan de Meyer * Martin Duke * Roy Fielding * Alan Frindell * Alessandro Ghedini * Nick Harper * Ryan Hamilton * Christian Huitema * Subodh Iyengar * Robin Malx * Patrick McManus * Luca Niccolini *奥Roberto Peon * Julian Reschke * Eric Rescorla * Martin Seemann * Ben Schwartz * Ian Swett * Willy Taureau * Martin Thomson * Dmitri Tikhonov * Tatsuhiro Tsujikawa
A portion of Mike Bishop's contribution was supported by Microsoft during his employment there.
マイク・ビショップの貢献の一部は、そこでの雇用中にマイクロソフトによって支持されました。
Index
索引
C D G H M P R S
C D G H M P R s
C
c
CANCEL_PUSH Section 2, Paragraph 5; Section 4.6, Paragraph 6;
Section 4.6, Paragraph 10; Table 1; *_Section 7.2.3_*;
Section 7.2.5, Paragraph 4.2.1; Section 7.2.7, Paragraph 1;
Table 2; Appendix A.2.5, Paragraph 1.8.1
connection error Section 2.2; Section 4.1, Paragraph 7;
Section 4.1, Paragraph 8; Section 4.4, Paragraph 8;
Section 4.4, Paragraph 10; Section 4.6, Paragraph 3;
Section 5.2, Paragraph 7; Section 6.1, Paragraph 3;
Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;
Section 6.2.1, Paragraph 2; Section 6.2.1, Paragraph 2;
Section 6.2.2, Paragraph 3; Section 6.2.2, Paragraph 6;
Section 7.1, Paragraph 5; Section 7.1, Paragraph 6;
Section 7.2.1, Paragraph 2; Section 7.2.2, Paragraph 3;
Section 7.2.3, Paragraph 5; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.4, Paragraph 2;
Section 7.2.4, Paragraph 3; Section 7.2.4, Paragraph 6;
Section 7.2.4.1, Paragraph 5; Section 7.2.4.2, Paragraph 8;
Section 7.2.4.2, Paragraph 8; Section 7.2.5, Paragraph 5;
Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 8;
Section 7.2.5, Paragraph 9; Section 7.2.6, Paragraph 3;
Section 7.2.6, Paragraph 5; Section 7.2.7, Paragraph 2;
Section 7.2.7, Paragraph 3; Section 7.2.7, Paragraph 6;
Section 7.2.8, Paragraph 3; *_Section 8_*; Section 10.5,
Paragraph 7; Appendix A.4.1, Paragraph 4
control stream Section 2, Paragraph 3; Section 3.2, Paragraph
4; Section 6.2, Paragraph 3; Section 6.2, Paragraph 5;
Section 6.2, Paragraph 6; *_Section 6.2.1_*; Section 7,
Paragraph 1; Section 7.2.1, Paragraph 2; Section 7.2.2,
Paragraph 3; Section 7.2.3, Paragraph 5; Section 7.2.3,
Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,
Paragraph 2; Section 7.2.4, Paragraph 3; Section 7.2.5,
Paragraph 8; Section 7.2.6, Paragraph 3; Section 7.2.6,
Paragraph 5; Section 7.2.7, Paragraph 2; Section 8.1,
Paragraph 2.22.1; Section 9, Paragraph 4; Appendix A.2.4,
Paragraph 3; Appendix A.3, Paragraph 1
D
d
DATA Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item 2;
Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;
Section 4.1.2, Paragraph 3; Section 4.1.2, Paragraph 3;
Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;
Section 4.4, Paragraph 7; Section 4.4, Paragraph 7;
Section 4.4, Paragraph 8; Section 4.6, Paragraph 12;
Table 1; *_Section 7.2.1_*; Table 2; Appendix A.1, Paragraph
3; Appendix A.2.3, Paragraph 1; Appendix A.2.5
G
g
GOAWAY Section 3.3, Paragraph 5; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 1; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 2; Section 5.2, Paragraph 2;
Section 5.2, Paragraph 3; Section 5.2, Paragraph 5.1.1;
Section 5.2, Paragraph 5.1.1; Section 5.2, Paragraph 5.1.2;
Section 5.2, Paragraph 5.1.2; Section 5.2, Paragraph 5, Item
2; Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph
6; Section 5.2, Paragraph 6; Section 5.2, Paragraph 7;
Section 5.2, Paragraph 7; Section 5.2, Paragraph 8;
Section 5.2, Paragraph 8; Section 5.2, Paragraph 9;
Section 5.2, Paragraph 9; Section 5.2, Paragraph 10;
Section 5.2, Paragraph 12; Section 5.3, Paragraph 2;
Section 5.3, Paragraph 2; Section 5.4, Paragraph 2; Table 1;
*_Section 7.2.6_*; Table 2; Appendix A.2.5; Appendix A.2.5,
Paragraph 1.16.1
H
h
H3_CLOSED_CRITICAL_STREAM Section 6.2.1, Paragraph 2;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1
H3_CONNECT_ERROR Section 4.4, Paragraph 10; Section 8.1;
Table 4; Appendix A.4, Paragraph 3.22.1
H3_EXCESSIVE_LOAD Section 8.1; Section 10.5, Paragraph 7;
Table 4; Appendix A.4, Paragraph 3.24.1
H3_FRAME_ERROR Section 7.1, Paragraph 5; Section 7.1,
Paragraph 6; Section 8.1; Table 4; Appendix A.4, Paragraph
3.14.1
H3_FRAME_UNEXPECTED Section 4.1, Paragraph 7; Section 4.1,
Paragraph 8; Section 4.4, Paragraph 8; Section 7.2.1,
Paragraph 2; Section 7.2.2, Paragraph 3; Section 7.2.3,
Paragraph 5; Section 7.2.4, Paragraph 2; Section 7.2.4,
Paragraph 3; Section 7.2.5, Paragraph 8; Section 7.2.5,
Paragraph 9; Section 7.2.6, Paragraph 5; Section 7.2.7,
Paragraph 2; Section 7.2.7, Paragraph 3; Section 7.2.8,
Paragraph 3; Section 8.1; Table 4; Appendix A.4, Paragraph
3.4.1
H3_GENERAL_PROTOCOL_ERROR Section 7.2.5, Paragraph 6;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.4.1
H3_ID_ERROR Section 4.6, Paragraph 3; Section 5.2, Paragraph
7; Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.5, Paragraph 5;
Section 7.2.6, Paragraph 3; Section 7.2.7, Paragraph 6;
Section 8.1; Table 4
H3_INTERNAL_ERROR Section 8.1; Table 4; Appendix A.4,
Paragraph 3.6.1
H3_MESSAGE_ERROR Section 4.1.2, Paragraph 4; Section 8.1;
Table 4; Appendix A.4, Paragraph 3.4.1
H3_MISSING_SETTINGS Section 6.2.1, Paragraph 2; Section 8.1;
Table 4
H3_NO_ERROR Section 4.1, Paragraph 15; Section 5.2, Paragraph
11; Section 6.2.3, Paragraph 2; Section 8, Paragraph 5;
Section 8.1; Section 8.1, Paragraph 3; Section 8.1,
Paragraph 3; Table 4; Appendix A.4, Paragraph 3.2.1
H3_REQUEST_CANCELLED Section 4.1.1, Paragraph 4;
Section 4.1.1, Paragraph 5; Section 4.6, Paragraph 14;
Section 7.2.3, Paragraph 3; Section 7.2.3, Paragraph 4;
Section 8.1; Table 4; Appendix A.4, Paragraph 3.18.1;
Appendix A.4.1, Paragraph 3
H3_REQUEST_INCOMPLETE Section 4.1, Paragraph 14; Section 8.1;
Table 4
H3_REQUEST_REJECTED Section 4.1.1, Paragraph 3; Section 4.1.1,
Paragraph 4; Section 4.1.1, Paragraph 5; Section 4.1.1,
Paragraph 5; Section 8.1; Table 4; Appendix A.4, Paragraph
3.16.1; Appendix A.4.1, Paragraph 3
H3_SETTINGS_ERROR Section 7.2.4, Paragraph 6; Section 7.2.4.1,
Paragraph 5; Section 7.2.4.2, Paragraph 8; Section 7.2.4.2,
Paragraph 8; Section 8.1; Table 4
H3_STREAM_CREATION_ERROR Section 6.1, Paragraph 3;
Section 6.2, Paragraph 7; Section 6.2.1, Paragraph 2;
Section 6.2.2, Paragraph 3; Section 8.1; Table 4
H3_VERSION_FALLBACK Section 8.1; Table 4; Appendix A.4,
Paragraph 3.28.1
HEADERS Section 2, Paragraph 3; Section 4.1, Paragraph 5, Item
1; Section 4.1, Paragraph 5, Item 3; Section 4.1, Paragraph
7; Section 4.1, Paragraph 7; Section 4.1, Paragraph 7;
Section 4.1, Paragraph 10; Section 4.4, Paragraph 6;
Section 4.6, Paragraph 12; Table 1; *_Section 7.2.2_*;
Section 9, Paragraph 5; Table 2; Appendix A.2.1, Paragraph
1; Appendix A.2.5; Appendix A.2.5, Paragraph 1.4.1;
Appendix A.2.5, Paragraph 1.20.1
M
m
malformed Section 4.1, Paragraph 3; *_Section 4.1.2_*;
Section 4.2, Paragraph 2; Section 4.2, Paragraph 3;
Section 4.2, Paragraph 5; Section 4.3, Paragraph 3;
Section 4.3, Paragraph 4; Section 4.3.1, Paragraph 5;
Section 4.3.2, Paragraph 1; Section 4.4, Paragraph 5;
Section 8.1, Paragraph 2.30.1; Section 10.3, Paragraph 1;
Section 10.3, Paragraph 2; Section 10.5.1, Paragraph 2
MAX_PUSH_ID Section 2, Paragraph 5; Section 4.6, Paragraph 3;
Section 4.6, Paragraph 3; Section 4.6, Paragraph 3;
Section 4.6, Paragraph 3; Table 1; Section 7.2.5, Paragraph
5; *_Section 7.2.7_*; Table 2; Appendix A.1, Paragraph 4;
Appendix A.3, Paragraph 4.4.1
P
p
push ID *_Section 4.6_*; Section 5.2, Paragraph 1;
Section 5.2, Paragraph 5, Item 2; Section 5.2, Paragraph 9;
Section 6.2.2, Paragraph 2; Section 6.2.2, Paragraph 6;
Section 6.2.2, Paragraph 6; Section 7.2.3, Paragraph 1;
Section 7.2.3, Paragraph 7; Section 7.2.3, Paragraph 7;
Section 7.2.3, Paragraph 8; Section 7.2.3, Paragraph 8;
Section 7.2.5, Paragraph 4.2.1; Section 7.2.5, Paragraph 5;
Section 7.2.5, Paragraph 5; Section 7.2.5, Paragraph 6;
Section 7.2.5, Paragraph 6; Section 7.2.5, Paragraph 7;
Section 7.2.5, Paragraph 7; Section 7.2.5, Paragraph 7;
Section 7.2.6, Paragraph 4; Section 7.2.7, Paragraph 1;
Section 7.2.7, Paragraph 4; Section 7.2.7, Paragraph 4;
Section 7.2.7, Paragraph 6; Section 7.2.7, Paragraph 6;
Section 8.1, Paragraph 2.18.1; Appendix A.2.5, Paragraph
1.12.1; Appendix A.2.5, Paragraph 1.16.1
push stream Section 4.1, Paragraph 8; Section 4.1, Paragraph
9; Section 4.6, Paragraph 3; Section 4.6, Paragraph 5;
Section 4.6, Paragraph 5; Section 4.6, Paragraph 13;
Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;
Section 6.2, Paragraph 3; *_Section 6.2.2_*; Section 7,
Paragraph 1; Section 7.2.2, Paragraph 3; Section 7.2.3,
Paragraph 1; Section 7.2.3, Paragraph 2; Section 7.2.3,
Paragraph 2; Section 7.2.3, Paragraph 2; Section 7.2.3,
Paragraph 2; Section 7.2.3, Paragraph 3; Section 7.2.3,
Paragraph 4; Section 7.2.3, Paragraph 4; Section 7.2.3,
Paragraph 4; Section 7.2.5, Paragraph 4.2.1; Section 7.2.7,
Paragraph 1; Appendix A.2.5, Paragraph 1.12.1
PUSH_PROMISE Section 2, Paragraph 5; Section 4.1, Paragraph 8;
Section 4.1, Paragraph 8; Section 4.1, Paragraph 8;
Section 4.1, Paragraph 8; Section 4.1, Paragraph 10;
Section 4.6, Paragraph 4; Section 4.6, Paragraph 10;
Section 4.6, Paragraph 11; Section 4.6, Paragraph 11;
Section 4.6, Paragraph 12; Section 4.6, Paragraph 12;
Section 4.6, Paragraph 13; Section 4.6, Paragraph 13;
Section 4.6, Paragraph 13; Table 1; Section 7.2.3, Paragraph
8; Section 7.2.3, Paragraph 8; *_Section 7.2.5_*;
Section 7.2.7, Paragraph 1; Section 10.4, Paragraph 1;
Section 10.5, Paragraph 2; Table 2; Appendix A.2.5;
Appendix A.2.5, Paragraph 1.12.1; Appendix A.2.5, Paragraph
1.12.1; Appendix A.2.5, Paragraph 1.20.1
R
r
request stream Section 4.1, Paragraph 1; Section 4.1,
Paragraph 15; Section 4.1, Paragraph 15; Section 4.1.1,
Paragraph 1; Section 4.1.1, Paragraph 5; Section 4.4,
Paragraph 5; Section 4.4, Paragraph 9; Section 4.6,
Paragraph 4; Section 4.6, Paragraph 4; Section 4.6,
Paragraph 11; Section 4.6, Paragraph 11; *_Section 6.1_*;
Section 7, Paragraph 1; Section 7.2.2, Paragraph 3;
Section 7.2.5, Paragraph 1
S
s
SETTINGS Section 3.2, Paragraph 4; Section 3.2, Paragraph 4;
Section 6.2.1, Paragraph 2; Table 1; Section 7, Paragraph 3;
*_Section 7.2.4_*; Section 8.1, Paragraph 2.20.1;
Section 8.1, Paragraph 2.22.1; Section 9, Paragraph 4;
Section 10.5, Paragraph 4; Table 2; Table 4; Table 4;
Appendix A.2.5; Appendix A.2.5, Paragraph 1.10.1;
Appendix A.3, Paragraph 2; Appendix A.3, Paragraph 3;
Appendix A.3, Paragraph 4.4.1; Appendix A.3, Paragraph
4.6.1; Appendix A.3, Paragraph 4.8.1; Appendix A.3,
Paragraph 4.10.1; Appendix A.4, Paragraph 3.10.1
SETTINGS_MAX_FIELD_SECTION_SIZE Section 4.2.2, Paragraph 2;
Section 7.2.4.1; Section 10.5.1, Paragraph 2; Appendix A.3,
Paragraph 4.12.1
stream error Section 2.2; Section 4.1.2, Paragraph 4;
Section 4.4, Paragraph 10; *_Section 8_*; Appendix A.4.1,
Paragraph 3; Appendix A.4.1, Paragraph 3; Appendix A.4.1,
Paragraph 4
Author's Address
著者の住所
Mike Bishop (editor) Akamai Email: mbishop@evequefou.be
マイク・ビショップ（編集者）アカマイメール：mbishop@evequefou.be