[要約] RFC 9292は、HTTPメッセージをバイナリ形式で表現するための規定を定めています。その目的は、HTTPメッセージの効率的な処理と転送を可能にすることです。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 9292 Mozilla
Category: Standards Track C. A. Wood
ISSN: 2070-1721 Cloudflare
August 2022
Binary Representation of HTTP Messages
HTTPメッセージのバイナリ表現
Abstract
概要
This document defines a binary format for representing HTTP messages.
このドキュメントは、HTTPメッセージを表すためのバイナリ形式を定義します。
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/rfc9292.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9292で取得できます。
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
2. Conventions and Definitions
3. Format
3.1. Known-Length Messages
3.2. Indeterminate-Length Messages
3.3. Framing Indicator
3.4. Request Control Data
3.5. Response Control Data
3.5.1. Informational Status Codes
3.6. Header and Trailer Field Lines
3.7. Content
3.8. Padding and Truncation
4. Invalid Messages
5. Examples
5.1. Request Example
5.2. Response Example
6. Notable Differences with HTTP Protocol Messages
7. "message/bhttp" Media Type
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
This document defines a simple format for representing an HTTP message [HTTP], either request or response. This allows for the encoding of HTTP messages that can be conveyed outside an HTTP protocol. This enables the transformation of entire messages, including the application of authenticated encryption.
このドキュメントは、要求または応答のいずれかのHTTPメッセージ[HTTP]を表すための簡単な形式を定義します。これにより、HTTPプロトコルの外部で伝達できるHTTPメッセージのエンコードが可能になります。これにより、認証された暗号化の適用を含むメッセージ全体の変換が可能になります。
The design of this format is informed by the framing structure of HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3]. Rules for constructing messages rely on the rules defined in HTTP/2, but the format itself is distinct; see Section 6.
この形式の設計は、HTTP/2 [HTTP/2]およびHTTP/3 [HTTP/3]のフレーミング構造によって通知されます。メッセージを構築するためのルールは、HTTP/2で定義されているルールに依存していますが、形式自体は異なります。セクション6を参照してください。
This format defines "message/bhttp", a binary alternative to the "message/http" content type defined in [HTTP/1.1]. A binary format permits more efficient encoding and processing of messages. A binary format also reduces exposure to security problems related to processing of HTTP messages.
この形式は、[http/1.1]で定義されている「メッセージ/http」コンテンツタイプに代わるバイナリの代替品である「メッセージ/bhttp」を定義します。バイナリ形式では、メッセージのより効率的なエンコードと処理を可能にします。また、バイナリ形式は、HTTPメッセージの処理に関連するセキュリティ問題への露出を減らします。
Two modes for encoding are described:
エンコード用の2つのモードについて説明します。
* a known-length encoding includes length prefixes for all major message components, and
* 既知の長さのエンコードには、すべての主要なメッセージコンポーネントの長さのプレフィックスが含まれます。
* an indeterminate-length encoding enables efficient generation of messages where lengths are not known when encoding starts.
* 不定の長さのエンコードにより、エンコードが始まるときに長さが不明なメッセージの生成を効率的に生成できます。
This format is designed to convey the semantics of valid HTTP messages as simply and efficiently as possible. It is not designed to capture all of the details of the encoding of messages from specific HTTP versions [HTTP/1.1] [HTTP/2] [HTTP/3]. As such, this format is unlikely to be suitable for applications that depend on an exact recording of the encoding of messages.
この形式は、有効なHTTPメッセージのセマンティクスを可能な限り簡単かつ効率的に伝えるように設計されています。特定のHTTPバージョン[HTTP/1.1] [HTTP/2] [HTTP/3]からのメッセージのエンコードのすべての詳細をキャプチャするようには設計されていません。そのため、この形式は、メッセージのエンコードの正確な記録に依存するアプリケーションに適している可能性は低いです。
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 terminology from HTTP [HTTP] and notation from QUIC (Section 1.3 of [QUIC]).
このドキュメントでは、HTTP [HTTP]の用語とQUICからの表記法（[QUIC]のセクション1.3）を使用しています。
Section 6 of [HTTP] defines the general structure of HTTP messages and composes those messages into distinct parts. This format describes how those parts are composed into a sequence of bytes. At a high level, binary messages are comprised of:
[HTTP]のセクション6では、HTTPメッセージの一般的な構造を定義し、それらのメッセージを異なる部分に構成します。この形式は、これらの部品がバイトのシーケンスにどのように構成されているかを説明します。高レベルでは、バイナリメッセージは次のとおりです。
1. Framing indicator. This format uses a single integer to describe framing, which describes whether the message is a request or response and how subsequent sections are formatted; see Section 3.3.
1. フレーミングインジケーター。この形式では、単一の整数を使用してフレーミングを記述します。これは、メッセージがリクエストまたは応答であるかどうか、およびその後のセクションがどのようにフォーマットされるかを説明します。セクション3.3を参照してください。
2. For a response, zero or more informational responses. Each informational response consists of an informational status code and header section.
2. 応答の場合、ゼロ以上の情報応答。各情報応答は、情報ステータスコードとヘッダーセクションで構成されています。
3. Control data. For a request, this contains the request method and target. For a response, this contains the status code.
3. 制御データ。リクエストのために、これにはリクエスト方法とターゲットが含まれます。応答の場合、これにはステータスコードが含まれます。
4. Header section. This contains zero or more header fields.
4. ヘッダーセクション。これには、ゼロ以上のヘッダーフィールドが含まれます。
5. Content. This is a sequence of zero or more bytes.
5. コンテンツ。これは、ゼロ以上のバイトのシーケンスです。
6. Trailer section. This contains zero or more trailer fields.
6. トレーラーセクション。これには、ゼロ以上のトレーラーフィールドが含まれます。
7. Optional padding. Any amount of zero-valued bytes.
7. オプションのパディング。ゼロ値バイトの量。
All lengths and numeric values are encoded using the variable-length integer encoding from Section 16 of [QUIC]. Integer values do not need to be encoded on the minimum number of bytes necessary.
すべての長さと数値は、[QUIC]のセクション16からの可変長整数エンコードを使用してエンコードされます。整数値は、必要な最小バイト数でエンコードする必要はありません。
A request or response that has a known length at the time of construction uses the format shown in Figure 1.
建設時に既知の長さのリクエストまたは応答は、図1に示す形式を使用します。
Known-Length Request {
Framing Indicator (i) = 0,
Request Control Data (..),
Known-Length Field Section (..),
Known-Length Content (..),
Known-Length Field Section (..),
Padding (..),
}
Known-Length Response {
Framing Indicator (i) = 1,
Known-Length Informational Response (..) ...,
Final Response Control Data (..),
Known-Length Field Section (..),
Known-Length Content (..),
Known-Length Field Section (..),
Padding (..),
}
Known-Length Field Section {
Length (i),
Field Line (..) ...,
}
Known-Length Content {
Content Length (i),
Content (..),
}
Known-Length Informational Response {
Informational Response Control Data (..),
Known-Length Field Section (..),
}
Figure 1: Known-Length Message
図1：既知の長さのメッセージ
A known-length request consists of a framing indicator (Section 3.3), request control data (Section 3.4), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding.
既知の長さの要求は、フレーミングインジケーター（セクション3.3）、リクエスト制御データ（セクション3.4）、長さのプレフィックスを備えたヘッダーセクション、長さのプレフィックス付きバイナリコンテンツ、長さのプレフィックス付きトレーラーセクション、およびパディングで構成されています。
A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (Section 3.5.1) followed by response control data (Section 3.5).
既知の長さの応答には、同じフィールドが含まれていますが、要求制御データがゼロ以上の情報応答（セクション3.5.1）に置き換えられ、それに続く応答制御データ（セクション3.5）に置き換えられます。
For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer. This integer is the number of bytes in the field section or content, not including the length field itself.
既知の長さのエンコーディングの場合、フィールドセクションとコンテンツの長さのプレフィックスは、整数の可変長エンコードです。この整数は、フィールドセクションまたはコンテンツのバイト数であり、長さフィールド自体は含まれません。
Fields in the header and trailer sections consist of a length-prefixed name and length-prefixed value; see Section 3.6.
ヘッダーとトレーラーのセクションのフィールドは、長さが修正された名前と長さが埋められた値で構成されています。セクション3.6を参照してください。
The format allows for the message to be truncated before any of the length prefixes that precede the field sections or content; see Section 3.8.
この形式により、フィールドセクションまたはコンテンツの前にある長さのプレフィックスのいずれかの前に、メッセージを切り捨てることができます。セクション3.8を参照してください。
The variable-length integer encoding means that there is a limit of 2^62-1 bytes for each field section and the message content.
可変長さの整数エンコードは、各フィールドセクションとメッセージコンテンツに2^62-1バイトの制限があることを意味します。
A request or response that is constructed without encoding a known length for each section uses the format shown in Figure 2:
各セクションの既知の長さをエンコードせずに構築されるリクエストまたは応答は、図2に示す形式を使用します。
Indeterminate-Length Request {
Framing Indicator (i) = 2,
Request Control Data (..),
Indeterminate-Length Field Section (..),
Indeterminate-Length Content (..),
Indeterminate-Length Field Section (..),
Padding (..),
}
Indeterminate-Length Response {
Framing Indicator (i) = 3,
Indeterminate-Length Informational Response (..) ...,
Final Response Control Data (..),
Indeterminate-Length Field Section (..),
Indeterminate-Length Content (..),
Indeterminate-Length Field Section (..),
Padding (..),
}
Indeterminate-Length Content {
Indeterminate-Length Content Chunk (..) ...,
Content Terminator (i) = 0,
}
Indeterminate-Length Content Chunk {
Chunk Length (i) = 1..,
Chunk (..),
}
Indeterminate-Length Field Section {
Field Line (..) ...,
Content Terminator (i) = 0,
}
Indeterminate-Length Informational Response {
Informational Response Control Data (..),
Indeterminate-Length Field Section (..),
}
Figure 2: Indeterminate-Length Message
図2：不定の長さのメッセージ
An indeterminate-length request consists of a framing indicator (Section 3.3), request control data (Section 3.4), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding.
不確定な長さの要求は、フレーミングインジケーター（セクション3.3）、要求制御データ（セクション3.4）、ゼロ値で終了するヘッダーセクション、バイナリコンテンツのゼロ以外のチャンク、ゼロ値で構成されています。、ゼロ値とパディングで終了するトレーラーセクション。
An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (Section 3.5.1) and response control data (Section 3.5).
リクエスト制御データがゼロ以上の情報応答（セクション3.5.1）および応答制御データ（セクション3.5）に置き換えられることを除いて、不確定な長さの応答には同じフィールドが含まれています。
The indeterminate-length encoding only uses length prefixes for content blocks. Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block. The Chunk Length is encoded as a variable-length integer.
不定の長さのエンコードは、コンテンツブロックに長さのプレフィックスのみを使用します。コンテンツの複数の長さが埋められた部分を含めることができ、それぞれがブロック内のバイト数を記述する非ゼロチャンク長整数によって接頭辞を付けます。チャンクの長さは、可変長整数としてエンコードされます。
Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field. An Indeterminate-Length Field Section ends with a Content Terminator field. The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0.
不確定な長さのフィールドセクションの各フィールドラインは、名前の長さフィールドから始まります。コンテンツターミネーターフィールドで終了します。コンテンツターミネーターのゼロ値は、値0を含めることができない名前の長さフィールドと区別します。
Indeterminate-length messages can be truncated in a way similar to that for known-length messages; see Section 3.8.
既知の長さのメッセージと同様の方法で、既知の長さのメッセージと同様の方法で切り捨てられる可能性があります。セクション3.8を参照してください。
Indeterminate-length messages use the same encoding for Field Line as known-length messages; see Section 3.6.
不確定な長さのメッセージは、既知の長さのメッセージと同じエンコードをフィールドラインに使用します。セクション3.6を参照してください。
The start of each binary message is a framing indicator that is a single integer that describes the structure of the subsequent sections. The framing indicator can take just four values:
各バイナリメッセージの開始は、後続のセクションの構造を説明する単一の整数であるフレーミングインジケーターです。フレーミングインジケーターは、4つの値だけを取ることができます。
* A value of 0 describes a request of known length.
* 0の値は、既知の長さの要求を記述します。
* A value of 1 describes a response of known length.
* 1の値は、既知の長さの応答を表します。
* A value of 2 describes a request of indeterminate length.
* 2の値は、不定の長さの要求を説明しています。
* A value of 3 describes a response of indeterminate length.
* 3の値は、不定の長さの応答を記述します。
Other values cause the message to be invalid; see Section 4.
他の値はメッセージを無効にします。セクション4を参照してください。
The control data for a request message contains the method and request target. That information is encoded as an ordered sequence of fields: Method, Scheme, Authority, Path. Each of these fields is prefixed with a length.
要求メッセージの制御データには、メソッドとリクエストのターゲットが含まれています。その情報は、メソッド、スキーム、権威、パスの順序付けられたシーケンスのフィールドとしてエンコードされます。これらの各フィールドには、長さが付いています。
The values of these fields follow the rules in HTTP/2 (Section 8.3.1 of [HTTP/2]) that apply to the ":method", ":scheme", ":authority", and ":path" pseudo-header fields, respectively. However, where the ":authority" pseudo-header field might be omitted in HTTP/2, a zero-length value is encoded instead.
これらのフィールドの値は、「：方法」、「スキーム」、「権威」、および「パス」pseudo-に適用されるhttp/2（[http/2]のセクション8.3.1）のルールに従います。それぞれヘッダーフィールド。ただし、HTTP/2で「：権限」の疑似ヘッダーフィールドが省略される場合、代わりにゼロ長値がエンコードされます。
The format of request control data is shown in Figure 3.
リクエスト制御データの形式を図3に示します。
Request Control Data {
Method Length (i),
Method (..),
Scheme Length (i),
Scheme (..),
Authority Length (i),
Authority (..),
Path Length (i),
Path (..),
}
Figure 3: Format of Request Control Data
図3：要求制御データの形式
The control data for a response message consists of the status code. The status code (Section 15 of [HTTP]) is encoded as a variable-length integer, not a length-prefixed decimal string.
応答メッセージの制御データは、ステータスコードで構成されています。ステータスコード（[http]のセクション15）は、長さの垂直整数ではなく、可変長整数としてエンコードされます。
The format of final response control data is shown in Figure 4.
最終応答制御データの形式を図4に示します。
Final Response Control Data {
Status Code (i) = 200..599,
}
Figure 4: Format of Final Response Control Data
図4：最終応答制御データの形式
Responses that include informational status codes (see Section 15.2 of [HTTP]) are encoded by repeating the response control data and associated header section until a final status code is encoded; that is, a Status Code field with a value from 200 to 599 (inclusive). The status code distinguishes between informational and final responses.
情報ステータスコード（[HTTP]のセクション15.2を参照）を含む応答は、最終的なステータスコードがエンコードされるまで応答制御データと関連するヘッダーセクションを繰り返すことによりエンコードされます。つまり、値が200から599（包括的）のステータスコードフィールドです。ステータスコードは、情報応答と最終的な応答を区別します。
The format of the informational response control data is shown in Figure 5.
情報応答制御データの形式を図5に示します。
Informational Response Control Data {
Status Code (i) = 100..199,
}
Figure 5: Format of Informational Response Control Data
図5：情報応答制御データの形式
A response message can include any number of informational responses that precede a final status code. These convey an informational status code and a header block.
応答メッセージには、最終的なステータスコードに先行する数の情報応答を含めることができます。これらは、情報ステータスコードとヘッダーブロックを伝えます。
If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is followed by a header section (encoded with known length or indeterminate length according to the framing indicator) and another block of control data. This pattern repeats until the control data contains a final status code (200 to 599 inclusive).
応答制御データに情報ステータスコード（つまり、100〜199の包括的値）が含まれている場合、制御データの後にヘッダーセクション（フレーミングインジケーターに応じて既知の長さまたは不確定性の長さがエンコード）と別のブロックが続きます。制御データ。このパターンは、制御データに最終的なステータスコード（200〜599インクルーシブ）が含まれるまで繰り返されます。
Header and trailer sections consist of zero or more field lines; see Section 5 of [HTTP]. The format of a field section depends on whether the message is of known length or indeterminate length.
ヘッダーとトレーラーのセクションは、ゼロ以上のフィールドラインで構成されています。[http]のセクション5を参照してください。フィールドセクションの形式は、メッセージが既知の長さであるか不確定な長さであるかによって異なります。
Each Field Line encoding includes a name and a value. Both the name and value are length-prefixed sequences of bytes. The Name field is a minimum of one byte. The format of a Field Line is shown in Figure 6.
各フィールドラインエンコーディングには、名前と値が含まれます。名前と値の両方は、バイトの長さが埋められたシーケンスです。名前フィールドは最低1バイトです。フィールドラインの形式を図6に示します。
Field Line {
Name Length (i) = 1..,
Name (..),
Value Length (i),
Value (..),
}
Figure 6: Format of a Field Line
図6：フィールドラインの形式
For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see Section 5.1 of [HTTP] for a definition of what is valid and Section 4 regarding the handling of invalid messages. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed according to Section 8.2.1 of [HTTP/2] as invalid; see Section 4.
フィールド名の場合、HTTPフィールド名で許可されていないバイト値は、メッセージが無効になります。無効なメッセージの処理に関する有効なものの定義とセクション4の定義については、[http]のセクション5.1を参照してください。受信者は、[HTTP/2]のセクション8.2.1に従ってHTTP/2メッセージを不正にしているフィールド値を含むメッセージを無効として扱う必要があります。セクション4を参照してください。
The same field name can be repeated over more than one field line; see Section 5.2 of [HTTP] for the semantics of repeated field names and rules for combining values.
同じフィールド名を複数のフィールドラインで繰り返すことができます。繰り返されるフィールド名と値を組み合わせたルールのセマンティクスについては、[http]のセクション5.2を参照してください。
Messages are invalid (Section 4) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status". Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see Section 8.1 of [HTTP/2]). A Field Line containing pseudo-fields MUST precede other Field Line values. A message that contains a pseudo-field after any other field is invalid; see Section 4.
メッセージは無効です（セクション4）それらには「：method "、"：scheme "、"：authority "、"：path "、または"：status "という名前のフィールドが含まれています。プロトコル拡張によって定義される他の擬似フィールドが含まれる場合があります。擬似フィールドはトレーラーに含めることはできません（[http/2]のセクション8.1を参照）。擬似フィールドを含むフィールドラインは、他のフィールドライン値に先行する必要があります。他のフィールドの後に擬似フィールドを含むメッセージは無効です。セクション4を参照してください。
Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be used to produce the effect on a connection in this context. These fields SHOULD be removed when constructing a binary message. However, they do not cause a message to be invalid (Section 4); permitting these fields allows a binary message to capture messages that are exchanged in a protocol context.
接続に関連するフィールド（[http]のセクション7.6.1）を使用して、このコンテキストで接続に効果を生成することはできません。これらのフィールドは、バイナリメッセージを作成するときに削除する必要があります。ただし、メッセージが無効になることはありません（セクション4）。これらのフィールドを許可すると、バイナリメッセージがプロトコルのコンテキストで交換されるメッセージをキャプチャできます。
Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the Cookie field. Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see Section 8.2.3 of [HTTP/2].
HTTP/2またはHTTP/3と同様に、この形式には、Cookieフィールドの複数のインスタンスの組み合わせの例外があります。「Cookie」のAscii-Encoded値を持つフィールドのインスタンスは、コンマではなくセミコロンオクテット（0x3b）を使用して組み合わされます。[http/2]のセクション8.2.3を参照してください。
The content of messages is a sequence of bytes of any length. Though a known-length message has a limit, this limit is large enough that it is unlikely to be a practical limitation. There is no limit to the size of content in an indeterminate-length message.
メッセージの内容は、任意の長さのバイトのシーケンスです。既知の長さのメッセージには制限がありますが、この制限は十分に大きく、実際的な制限である可能性は低いです。不確定な長さのメッセージにコンテンツのサイズに制限はありません。
Messages can be padded with any number of zero-valued bytes. Non-zero padding bytes cause a message to be invalid (see Section 4). Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes.
メッセージには、ゼロ値のゼロバイトを任意の数でパディングできます。ゼロ以外のパディングバイトにより、メッセージが無効になります（セクション4を参照）。メッセージの他の部分とは異なり、プロセッサはパディングバイトの値を検証しないことを決定する場合があります。
Truncation can be used to reduce the size of messages that have no data in trailing field sections or content. If the trailers of a message are empty, they MAY be omitted by the encoder in place of adding a length field equal to zero. An encoder MAY omit empty content in the same way if the trailers are also empty. A message that is truncated at any other point is invalid; see Section 4.
トランケーションは、トレーリングフィールドセクションまたはコンテンツにデータがないメッセージのサイズを削減するために使用できます。メッセージのトレーラーが空の場合、ゼロに等しい長さフィールドを追加する代わりにエンコーダーによって省略される場合があります。トレーラーも空である場合、エンコーダーは空のコンテンツを省略する場合があります。他のポイントで切り捨てられるメッセージは無効です。セクション4を参照してください。
Decoders MUST treat missing truncated fields as equivalent to having been sent with the length field set to zero.
デコーダーは、欠落している切り捨てられたフィールドを、長さのフィールドがゼロに設定されて送信されたことと同等であると扱う必要があります。
Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as a zero-length part, which is semantically equivalent to the part being absent.
パディングは、メッセージの空の部分の切り捨てと互換性があります。ゼロ値のバイトは、ゼロ長の部分として解釈され、これは部分的にパーツが存在しないことと同等です。
This document describes a number of ways that a message can be invalid. Invalid messages MUST NOT be processed further except to log an error and produce an error response.
このドキュメントは、メッセージが無効になる可能性のあるいくつかの方法について説明しています。エラーを記録してエラー応答を生成することを除いて、無効なメッセージをさらに処理してはなりません。
The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error might be detected after performing incremental processing.
この形式は、増分処理を可能にするように設計されています。実装は、増分処理を実行した後にエラーが検出される可能性を認識する必要があります。
This section includes example requests and responses encoded in both known-length and indeterminate-length forms.
このセクションには、既知の長さと不定の長さの両方のフォームでエンコードされたリクエストと応答の例が含まれています。
The example HTTP/1.1 message in Figure 7 shows the content in the "message/http" format.
図7のHTTP/1.1メッセージの例は、「メッセージ/HTTP」形式のコンテンツを示しています。
Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0d and 0x0a). For simplicity and consistency, the content of these examples is limited to text, which also uses CRLF for line endings.
有効なHTTP/1.1メッセージには、CRLF（2バイト0x0Dおよび0x0A）で終了した行が必要です。簡単にし、一貫性をとるために、これらの例の内容はテキストに限定されており、これはラインエンディングにもCRLFを使用します。
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Figure 7: Sample HTTP Request
図7：HTTP要求のサンプル
This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in Figure 8. Figure 8 includes text alongside to show that most of the content is not modified.
これは、図8の16進数に示すように、既知の長さのエンコードを使用して、バイナリメッセージ（「メッセージ/bhttp」とタイプ「メッセージ/bhttp」）として表現できます。図8には、コンテンツのほとんどが変更されていないことを示すテキストが含まれています。
00034745 54056874 74707300 0a2f6865 ..GET.https../he 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a 63636570 742d6c61 6e677561 67650665 ccept-language.e 6e2c206d 690000 n, mi..
0.9.7L Z 6C69622F 312E322E 3304686F 73740F77 LIB/1.2.3.HOST.W 77772E65 78616D70 6C652E63 6F6D0F61 ww.example.com.a 63636570
Figure 8: Known-Length Binary Encoding of Request
図8：リクエストの既知の長さのバイナリエンコーディング
This example shows that the Host header field is not replicated in the ":authority" field, as is required for ensuring that the request is reproduced accurately; see Section 8.3.1 of [HTTP/2].
この例は、リクエストが正確に再現されることを保証するために必要なように、ホストヘッダーフィールドが「：権限」フィールドで複製されていないことを示しています。[http/2]のセクション8.3.1を参照してください。
The same message can be truncated with no effect on interpretation. In this case, the last two bytes -- corresponding to content and a trailer section -- can each be removed without altering the semantics of the message.
同じメッセージは、解釈に影響を与えずに切り捨てられる可能性があります。この場合、コンテンツとトレーラーセクションに対応する最後の2バイトは、メッセージのセマンティクスを変更せずにそれぞれ削除できます。
The same message, encoded using an indeterminate-length encoding, is shown in Figure 9. As the content of this message is empty, the difference in formats is negligible.
不定の長さのエンコードを使用してエンコードされた同じメッセージを図9に示します。このメッセージの内容が空であるため、形式の違いは無視できます。
02034745 54056874 74707300 0a2f6865 ..GET.https../he
6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age
6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l
69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op
656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli
622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www
2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc
6570742d 6c616e67 75616765 06656e2c ept-language.en,
206d6900 00000000 00000000 00000000 mi.............
Figure 9: Indeterminate-Length Binary Encoding of Request
図9：リクエストの不定の長さのバイナリエンコーディング
This indeterminate-length encoding contains 10 bytes of padding. As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning.
この不定の長さのエンコーディングには、10バイトのパディングが含まれています。既知の長さの例と同じ方法で2つの追加バイトを切り捨てることができるため、その意味に影響を与えることなく、このメッセージから最大12バイトを削除できます。
Response messages can contain interim (1xx) status codes, as the message in Figure 10 shows. Figure 10 includes examples of informational status codes 102 and 103, as defined in [RFC2518] (now obsolete but defines status code 102) and [RFC8297], respectively.
図10のメッセージが示すように、応答メッセージには暫定（1xx）ステータスコードを含めることができます。図10には、[RFC2518]で定義されている情報ステータスコード102および103の例（現在は時代遅れですが、ステータスコード102を定義している）と[RFC8297]の例を示しています。
HTTP/1.1 102 Processing Running: "sleep 15"
HTTP/1.1 102処理ランニング：「スリープ15」
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.
「こんにちは世界」私のコンテンツには、後続のCRLFが含まれています。
Figure 10: Sample HTTP Response
図10：サンプルHTTP応答
As this is a longer example, only the indeterminate-length encoding is shown in Figure 11. Note here that the specific text used in the reason phrase is not retained by this encoding.
これはより長い例であるため、不定の長さのエンコードのみを図11に示します。ここでは、理由フレーズで使用される特定のテキストがこのエンコードによって保持されないことに注意してください。
03406607 72756e6e 696e670a 22736c65 .@f.running."sle
65702031 35220040 67046c69 6e6b233c ep 15".@g.link#<
2f737479 6c652e63 73733e3b 2072656c /style.css>; rel
3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty
6c65046c 696e6b24 3c2f7363 72697074 le.link$</script
2e6a733e 3b207265 6c3d7072 656c6f61 .js>; rel=preloa
643b2061 733d7363 72697074 0040c804 d; as=script.@..
64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul
20323030 39203132 3a32383a 35332047 2009 12:28:53 G
4d540673 65727665 72064170 61636865 MT.server.Apache
0d6c6173 742d6d6f 64696669 65641d57 .last-modified.W
65642c20 3232204a 756c2032 30303920 ed, 22 Jul 2009
31393a31 353a3536 20474d54 04657461 19:15:56 GMT.eta
67142233 34616133 38372d64 2d313536 g."34aa387-d-156
38656230 30220d61 63636570 742d7261 8eb00".accept-ra
6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte
6e742d6c 656e6774 68023531 04766172 nt-length.51.var
790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin
670c636f 6e74656e 742d7479 70650a74 g.content-type.t
6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello
20576f72 6c642120 4d792063 6f6e7465 World! My conte
6e742069 6e636c75 64657320 61207472 nt includes a tr
61696c69 6e672043 524c462e 0d0a0000 ailing CRLF.....
Figure 11: Binary Response, including Informational Responses
図11：情報応答を含むバイナリ応答
A response that uses the chunked encoding (see Section 7.1 of [HTTP/1.1]) as shown in Figure 12 can be encoded using indeterminate-length encoding, which minimizes buffering needed to translate into the binary format. However, chunk boundaries do not need to be retained, and any chunk extensions cannot be conveyed using the binary format; see Section 6.
図12に示すように、チャンクされたエンコード（[http/1.1]のセクション7.1を参照）を使用する応答は、バイナリ形式に変換するために必要なバッファリングを最小限に抑える不定レングスエンコードを使用してエンコードできます。ただし、チャンク境界を保持する必要はなく、バイナリ形式を使用してチャンク拡張機能を伝達することはできません。セクション6を参照してください。
HTTP/1.1 200 OK Transfer-Encoding: chunked
HTTP/1.1 200 OK転送エンコード：チャンク
4 This 6 conte 13;chunk-extension=foo nt contains CRLF.
4この6 conte 13; chunk-extension = foo ntにはcrlfが含まれています。
0 Trailer: text
0トレーラー：テキスト
Figure 12: Chunked Encoding Example
図12：チャンクされたエンコードの例
Figure 13 shows this message using the known-length encoding. Note that the Transfer-Encoding header field is removed.
図13は、既知の長さのエンコードを使用してこのメッセージを示しています。転送エンコードヘッダーフィールドが削除されていることに注意してください。
0140c800 1d546869 7320636f 6e74656e .@...This conten
7420636f 6e746169 6e732043 524c462e t contains CRLF.
0d0a0d07 74726169 6c657204 74657874 ....trailer.text
Figure 13: Known-Length Encoding of Response
図13：応答の既知の長さのエンコード
This format is designed to carry HTTP semantics just like HTTP/1.1 [HTTP/1.1], HTTP/2 [HTTP/2], or HTTP/3 [HTTP/3]. However, there are some notable differences between this format and the format used in an interactive protocol version.
この形式は、HTTP/1.1 [HTTP/1.1]、HTTP/2 [HTTP/2]、またはHTTP/3 [HTTP/3]のようにHTTPセマンティクスを運ぶように設計されています。ただし、この形式とインタラクティブプロトコルバージョンで使用される形式との間には、いくつかの顕著な違いがあります。
In particular, as a standalone representation, this format lacks the following features of the formats used in those protocols:
特に、スタンドアロン表現として、この形式には、これらのプロトコルで使用される形式の次の機能がありません。
* chunk extensions (Section 7.1.1 of [HTTP/1.1]) and transfer encoding (Section 6.1 of [HTTP/1.1])
* チャンク拡張機能（[http/1.1]のセクション7.1.1）および転送エンコード（[http/1.1]のセクション6.1））
* generic framing and extensibility capabilities
* 一般的なフレーミングと拡張性機能
* field blocks other than a single header and trailer field block
* 単一のヘッダーとトレーラーのフィールドブロック以外のフィールドブロック
* carrying reason phrases in responses (Section 4 of [HTTP/1.1])
* 応答で理由フレーズを運ぶ（[http/1.1]のセクション4）
* header compression [HPACK] [QPACK]
* ヘッダー圧縮[hpack] [qpack]
* response framing that depends on the corresponding request (such as HEAD) or the value of the status code (such as 204 or 304); these responses use the same framing as all other messages
* 対応する要求（ヘッドなど）またはステータスコードの値（204または304など）に依存する応答フレーミング。これらの応答は、他のすべてのメッセージと同じフレーミングを使用します
Some of these features are also absent in HTTP/2 and HTTP/3.
これらの機能のいくつかは、HTTP/2およびHTTP/3にも存在しません。
Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data rather than using pseudo-fields.
HTTP/2およびHTTP/3とは異なり、この形式は、擬似フィールドを使用するのではなく、制御データに固定形式を使用します。
Note that while some messages -- CONNECT or upgrade requests in particular -- can be represented using this format, doing so serves no purpose, as these requests are used to affect protocol behavior, which this format cannot do without additional mechanisms.
一部のメッセージ（特にリクエストを接続またはアップグレードする）はこの形式を使用して表現できますが、これらのリクエストはプロトコルの動作に影響を与えるために使用されるため、目的はありません。この形式は追加のメカニズムなしではできません。
The "message/bhttp" media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.
「メッセージ/BHTTP」メディアタイプは、行の長さとエンコーディングに関するすべての「メッセージ」タイプのMIME制限に従うことを条件に、単一のHTTP要求または応答メッセージを囲むために使用できます。
Type name: message
Subtype name: bhttp
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Only "8bit" or "binary" is permitted.
Security considerations: See Section 8.
Interoperability considerations: N/A
Published specification: RFC 9292
Applications that use this media type: Applications seeking to
convey HTTP semantics that are independent of a specific protocol.
Fragment identifier considerations: N/A
Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the
Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See the Authors' Addresses section.
Change controller: IESG
Many of the considerations that apply to HTTP message handling apply to this format; see Section 17 of [HTTP] and Section 11 of [HTTP/1.1] for common issues in handling HTTP messages.
HTTPメッセージ処理に適用される考慮事項の多くは、この形式に適用されます。HTTPメッセージの処理における一般的な問題については、[http]のセクション17および[http/1.1]のセクション11を参照してください。
Strict parsing of the format with no tolerance for errors can help avoid a number of attacks. However, implementations still need to be aware of the possibility of resource exhaustion attacks that might arise from receiving large messages, particularly those with large numbers of fields.
エラーに対する耐性のない形式の厳密な解析は、多くの攻撃を回避するのに役立ちます。ただし、実装は、大きなメッセージ、特に多数のフィールドを持つメッセージを受信することで生じる可能性のあるリソースの疲労攻撃の可能性を認識する必要があります。
Implementations need to ensure that they aren't subject to resource exhaustion attacks from maliciously crafted messages. Overall, the format is designed to allow for minimal state when processing messages. However, producing a combined field value (Section 5.2 of [HTTP]) for fields might require the commitment of resources. In particular, combining might be necessary for the Cookie field when translating this format for use in other contexts, such as use in an API or translation to HTTP/1.1 [HTTP/1.1], where the recipient of the field might not expect multiple values.
実装は、悪意のある作成されたメッセージからのリソース疲労攻撃の対象ではないことを確認する必要があります。全体として、この形式は、メッセージを処理するときに最小限の状態を可能にするように設計されています。ただし、フィールドの合計フィールド値（[HTTP]のセクション5.2）を作成するには、リソースのコミットメントが必要になる場合があります。特に、APIでの使用やHTTP/1.1 [HTTP/1.1]への翻訳など、他のコンテキストで使用するためにこの形式を翻訳する場合、Cookieフィールドに組み合わせることが必要になる場合があります。。
IANA has added the media type "message/bhttp" to the "Media Types" registry at <https://www.iana.org/assignments/media-types>. See Section 7 for registration information.
IANAは、<https://www.iana.org/assignments/media-types>の「メディアタイプ」レジストリにメディアタイプ「メッセージ/bhttp」を追加しました。登録情報については、セクション7を参照してください。
[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/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>。
[QUIC] 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] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[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>。
[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>。
[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/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[HTTP/3] Bishop、M.、ed。、 "HTTP/3"、RFC 9114、DOI 10.17487/RFC9114、2022年6月、<https://www.rfc-editor.org/info/rfc9114>。
[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>。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, <https://www.rfc-editor.org/info/rfc2518>.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav - RFC 2518、DOI 10.17487/RFC2518、1999年2月、<https://www.rfc-editor.org/info/rfc2518>。
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", RFC 8297, DOI 10.17487/RFC8297, December 2017, <https://www.rfc-editor.org/info/rfc8297>.
[RFC8297] OKU、K。、「ヒントを示すためのHTTPステータスコード」、RFC 8297、DOI 10.17487/RFC8297、2017年12月、<https://www.rfc-editor.org/info/rfc8297>
Acknowledgments
謝辞
Julian Reschke, David Schinazi, Lucas Pardue, and Tommy Pauly provided excellent feedback on both the design and its documentation.
Julian Reschke、David Schinazi、Lucas Pardue、およびTommy Paulyは、デザインとそのドキュメントの両方について優れたフィードバックを提供しました。
Authors' Addresses
著者のアドレス
Martin Thomson Mozilla Email: mt@lowentropy.net
Martin Thomson Mozillaメール：mt@lowentropy.net
Christopher A. Wood Cloudflare Email: caw@heapingbits.net
Christopher A. Wood Cloudflareメール：caw@heapingbits.net