1. 概要

2. 目的

3. 提案内容

4. タスク

[ ] 細かいタスクに分解できているなら書き出す

RFC 9112

要約

RFC 9112は、インターネット標準トラックの一部として、HTTP/1.1プロトコルの仕様を定義しています。この文書は、Web通信の基礎となるプロトコルのバージョン1.1に関する詳細な定義とガイドラインを提供し、メッセージの形式、接続の管理、エラーハンドリングなどをカバーしています。HTTP/1.1は、Webページのリクエストと配信に広く利用されており、インターネット上での情報交換の効率と信頼性を高めることを目的としています。関連するRFCには、RFC 7230（HTTP/1.1メッセージ構文とルーティング）、RFC 7231（HTTP/1.1セマンティクスとコンテンツ）、RFC 7232（HTTP/1.1条件付きリクエスト）、RFC 7233（HTTP/1.1レンジリクエスト）、RFC 7234（HTTP/1.1キャッシング）などがあります。RFC 9112はこれらのRFCを置き換え、HTTP/1.1に関する最新の標準を提供します。

1. Introduction

2. Message

An HTTP/1.1 message consists of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format [RFC5322]: zero or more header field lines (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. HTTP/1.1メッセージは、インターネットメッセージ形式[RFC5322]と同様の形式のCRLFとオクテットのシーケンスに続くスタートラインと続いて構成されています。「ヘッダーセクション」）、ヘッダーセクションの端を示す空の行、およびオプションのメッセージ本文。 HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ message-body ]

2.2. Message Parsing

[x] A recipient MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII [USASCII]. 受信者は、US-ASCII [USASCII]のスーパーセットであるエンコードのオクテットのシーケンスとしてHTTPメッセージを解析する必要があります。
encoding: データを一定の規則に従って目的の情報に変換すること(符号化)
octet: 8ビット
[x] A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the content. A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. 送信者は、コンテンツ以外のプロトコル要素内で、むき出しのCR（すぐにLFが続きません）を生成してはなりません。そのような場合、受信側は、処理したりメッセージを転送する前に、そのエレメントは無効であるとみなすか、各ベアCRをSPに置き換えなければならない(MUST)。
FL:改行(\r\n)のこと
[x] HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF. HTTP/1.1ユーザーエージェントはリクエストの前に余分なCRLFをつけてはならない
user agent : 「ネット利用者が使用しているOS・ブラウザ」のこと
[x] If terminating the request message body with a line-ending is desired, then the user agent MUST count the terminating CRLF octets as part of the message body length. リクエストメッセージボディを行末で終了することが望まれる場合、ユーザーエージェントは行末のCRLFオクテットをメッセージボディの長さの一部として数えなければならない[MUST]。
バイナリデータを送信する場合は、CRLFを含める必要なし
[x] A sender MUST NOT send whitespace between the start-line and the first header field. 送信者はスタートラインとヘッダーの間に空白行を送ってはいけない。
start-line : リクエストライン、もしくはステータスラインのこと
[x] A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated). 開始行と最初のヘッダーフィールドの間に空白を受け取る受信者は、そのメッセージを無効として拒否するか、空白で先行する各行をそれ以上処理せずに消費しなければならない[MUST](すなわち、適切に形成されたヘッダーフィールドを受け取るかヘッダーセクションが終了するまで、空白で先行するそれ以降の行と共にその行全体を無視する)。

2.3. HTTP Version

[x] Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages, unless it is purposefully downgraded as a workaround for an upstream issue. HTTPメッセージを処理する中継媒体(すなわち、トンネルとして動作する中継媒体以外のすべての中継媒体)は、上流の問題の回避策として意図的にダウングレードされない限り、転送されるメッセージに自身のHTTP-versionを送信しなければなりません(MUST)。

3. Request Line

[x] A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 15.5.15 of [HTTP]). 解析したいURIよりも長いリクエストターゲットを受け取るサーバーは、414(URI Too Long)ステータスコードで応答しなければならないMUST。
[x] A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. クライアントはすべてのHTTP/1.1リクエストメッセージでHostヘッダーフィールド(参考文献[HTTP]のセクション7.2)を送らなければなりません[MUST]。ターゲット URI が authority コンポーネントを含む場合、クライアントは userinfo サブコンポーネントとその "@" デリミタ ([HTTP] のセクション 4.2) を除いた、その authority コンポーネントと同一の Host フィールド値を送らなければなりません (MUST)。ターゲットURIに対してauthorityコンポーネントがないか未定義の場合、クライアントは空のフィールド値を持つHostヘッダーフィールドを送らなければならない[MUST]。
[x] A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field line or a Host header field with an invalid field value. サーバーは、Hostヘッダーフィールドを欠くHTTP/1.1リクエストメッセージと、一つ以上のHostヘッダーフィールド行を含むリクエストメッセージ、または無効なフィールド値を持つHostヘッダーフィールドに対して、400(Bad Request)ステータスコードで応答しなければならない[MUST]。 #143

3.2.1. origin-form

The most common form of request-target is the "origin-form". origin-form = absolute-path [ "?" query ]

[ ] When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 7.2 of [HTTP].

3.2.2. absolute-form 無視

[x] When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send the target URI in "absolute-form" as the request-target.接続またはサーバー全体のオプションリクエスト（以下の詳細）を除いて、プロキシにリクエストを行う場合、クライアントはターゲットURIをリクエストターゲットとして「Absolute-form」で送信する必要があります。absolute-form = absolute-URI
[x] A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.クライアントは、リクエストターゲットが絶対フォームにある場合でも、ホストヘッダーフィールドをHTTP/1.1リクエストで送信する必要があります。
[x] When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target.プロキシがリクエストターゲットの絶対形式でリクエストを受信した場合、プロキシは受信したホストヘッダーフィールドを無視し（もしあれば）、代わりにリクエストターゲットのホスト情報に置き換える必要があります。
[x] A proxy that forwards such a request MUST generate a new Host field value based on the received request-target rather than forward the received Host field value.そのような要求を転送するプロキシは、受信したホストフィールド値を転送するのではなく、受信した要求標的に基づいて新しいホストフィールド値を生成する必要があります。
[x] When an origin server receives a request with an absolute-form of request-target, the origin server MUST ignore the received Host header field (if any) and instead use the host information of the request-target. Note that if the request-target does not have an authority component, an empty Host header field will be sent in this case.Origin Serverがリクエストターゲットの絶対形式でリクエストを受信した場合、Origin Serverは受信したホストヘッダーフィールド（存在する場合）を無視し、代わりにリクエストターゲットのホスト情報を使用する必要があります。リクエストターゲットに権限コンポーネントがない場合、この場合は空のホストヘッダーフィールドが送信されることに注意してください。
[x] A server MUST accept the absolute-form in requests even though most HTTP/1.1 clients will only send the absolute-form to a proxy.ほとんどのHTTP/1.1クライアントは絶対フォームをプロキシに送信するだけであっても、サーバーはリクエストで絶対フォームを受け入れる必要があります。

authority-form 無視

The "authority-form" of request-target is only used for CONNECT requests (Section 9.3.6 of [HTTP]). It consists of only the uri-host and port number of the tunnel destination, separated by a colon (":"). リクエストターゲットの「権限形式」は、接続要求にのみ使用されます（[HTTP]のセクション9.3.6）。これは、コロン（ "："）で区切られたトンネルの目的地のURIホストとポート番号のみで構成されています。 authority-form = uri-host ":" port

[x] When making a CONNECT request to establish a tunnel through one or more proxies, a client MUST send only the host and port of the tunnel destination as the request-target. The client obtains the host and port from the target URI's authority component, except that it sends the scheme's default port if the target URI elides the port. 1つ以上のプロキシを介してトンネルを確立するための接続要求を作成する場合、クライアントはトンネルの宛先のホストとポートのみを要求ターゲットとして送信する必要があります。クライアントは、ターゲットURIがポートを削減する場合にスキームのデフォルトポートを送信することを除いて、ターゲットURIの権限コンポーネントからホストとポートを取得します。 For example, a CONNECT request to "http://www.example.com" looks like the following: たとえば、「http://www.example.com」への接続要求は次のようになります。 CONNECT www.example.com:80 HTTP/1.1 Host: www.example.com

3.2.4. asterisk-form 無視

The "asterisk-form" of request-target is only used for a server-wide OPTIONS request (Section 9.3.7 of [HTTP]). asterisk-form = "*"

[x] When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, the client MUST send only "" (%x2A) as the request-target. For example,クライアントがそのサーバーの特定の名前のリソースとは対照的に、クライアントがサーバー全体のオプションを要求したい場合、クライアントはリクエストターゲットとして「」（％x2a）のみを送信する必要があります。例えば、OPTIONS * HTTP/1.1
[x] If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of "" when it forwards the request to the indicated origin server.プロキシが、URIに空のパスがあり、クエリコンポーネントがないリクエストターゲットの絶対形式を使用してオプションリクエストを受信した場合、リクエストチェーンの最後のプロキシは「」のリクエストターゲットを送信する必要があります。指定されたOriginサーバーへの要求。 For example, the request OPTIONS http://www.example.org:8001 HTTP/1.1 would be forwarded by the final proxy as
```
OPTIONS * HTTP/1.1
Host: www.example.org:8001
```
after connecting to port 8001 of host "www.example.org".

4. Status Line

[ ] A server MUST send the space that separates the status-code from the reason-phrase even when the reason-phrase is absent (i.e., the status-line would end with the space).

5. Field Syntax

[ ] Each field line consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field line value, and optional trailing whitespace.
5.1. Field Line Parsing
[ ] No whitespace is allowed between the field name and colon.フィールド名とコロンの間には、空白は許可されていません。A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon. サーバーは、400の応答ステータスコード（悪い要求）を拒否する必要があります。
[ ] A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.プロキシは、メッセージを下流に転送する前に、応答メッセージからそのような空白を削除する必要があります。

5.2. Obsolete Line Folding

Historically, HTTP/1.x field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the "message/http" media type (Section 10.1).歴史的に、HTTP/1.xフィールド値は、少なくとも1つのスペースまたは水平タブ（obs倍）を持つ各追加線を前にすることにより、複数の線に拡張できます。この仕様は、「メッセージ/http」メディアタイプ（セクション10.1）内を除き、そのようなラインの折りたたみを非難します。 obs-fold = OWS CRLF RWS ; obsolete line folding
[ ] A sender MUST NOT generate a message that includes line folding (i.e., that has any field line value that contains a match to the obs-fold rule) unless the message is intended for packaging within the "message/http" media type.送信者は、メッセージが「メッセージ/http」メディアタイプ内のパッケージを目的としていない限り、行の折りたたみ（つまり、obs倍ルールに一致するフィールドライン値がある）を含むメッセージを生成してはなりません。
[ ] A server that receives an obs-fold in a request message that is not within a "message/http" container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.「メッセージ/http」コンテナ内にない要求メッセージで倍数を受信するサーバーは、400（悪い要求）を送信することでメッセージを拒否する必要があります。フィールド値を解釈するか、メッセージを下流に転送する前に、受信した各SPオクテットで断片を交換します。
[ ] A proxy or gateway that receives an obs-fold in a response message that is not within a "message/http" container MUST either discard the message and replace it with a 502 (Bad Gateway) response, preferably with a representation explaining that unacceptable line folding was received, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.「メッセージ/http」コンテナ内にない応答メッセージの倍数を受信するプロキシまたはゲートウェイは、メッセージを破棄し、502（悪いゲートウェイ）応答に置き換える必要があります。折りたたみを受け取ったか、フィールド値を解釈するか、下流のメッセージを転送する前に、受信した各SPオクテットで溶けます。
[ ] A user agent that receives an obs-fold in a response message that is not within a "message/http" container MUST replace each received obs-fold with one or more SP octets prior to interpreting the field value.「メッセージ/http」コンテナ内にない応答メッセージで倍数を受信するユーザーエージェントは、フィールド値を解釈する前に、受信した各SPオクテットにそれぞれ1つ以上のSPオクテットに置き換える必要があります。

6. Message Body

The message body (if any) of an HTTP/1.1 message is used to carry content (Section 6.4 of [HTTP]) for the request or response. The message body is identical to the content unless a transfer coding has been applied, as described in Section 6.1.HTTP/1.1メッセージのメッセージ本文（もしあれば）は、要求または応答のコンテンツ（[http]のセクション6.4）を運ぶために使用されます。セクション6.1で説明されているように、メッセージ本文は、転送コーディングが適用されない限り、コンテンツと同一です。message-body = *OCTET

6.1. Transfer-Encoding

[x] A recipient MUST be able to parse the chunked transfer coding (Section 7.1) because it plays a crucial role in framing messages when the content size is not known in advance.
[x] A sender MUST NOT apply the chunked transfer coding more than once to a message body (i.e., chunking an already chunked message is not allowed).
[x] If any transfer coding other than chunked is applied to a request's content, the sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.
[ ] If any transfer coding other than chunked is applied to a response's content, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection.
For example,Transfer-Encoding: gzip, chunkedindicates that the content has been compressed using the gzip coding and then chunked using the chunked coding while forming the message body.もしチャンク以外の転送コーディングがレスポンスのコンテンツに適用されている場合、送信者は最終的にチャンクを適用するか、接続を閉じてメッセージを終了しなければなりません。
[ ] A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Transfer-Encoding header field in any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of [HTTP]).サーバーは、1xxまたは204（コンテンツなし）のステータスコードを使用して、任意の応答で転送エンコードヘッダーフィールドを送信してはなりません。サーバーは、接続要求に対する2xx（成功）応答（[http]のセクション9.3.6）で転送エンコードヘッダーフィールドを送信してはなりません。
[ ] A client MUST NOT send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 requests (or later minor revisions); such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response. A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later minor revisions).クライアントは、サーバーがHTTP/1.1リクエスト（または後のマイナーリビジョン）を処理することがわかっていない限り、転送エンコードを含むリクエストを送信してはなりません。このような知識は、特定のユーザー構成の形であるか、以前に受信した応答のバージョンを覚えている可能性があります。対応する要求がHTTP/1.1（または後のマイナーリビジョン）を示していない限り、サーバーは転送エンコードを含む応答を送信してはなりません。
[ ] A server MAY reject a request that contains both Content-Length and Transfer-Encoding or process such a request in accordance with the Transfer-Encoding alone. Regardless, the server MUST close the connection after responding to such a request to avoid the potential attacks. サーバーは、コンテンツレングスと転送エンコードの両方を含むリクエストを拒否するか、転送エンコードのみに従ってそのような要求を処理する場合があります。とにかく、サーバーは、潜在的な攻撃を回避するためにそのような要求に応答した後、接続を閉じる必要があります。
Content-Length と Transfer-Encodingみたいな、潜在的な攻撃が来たときは接続を閉じた方が良さそう。
[ ] A server or client that receives an HTTP/1.0 message containing a Transfer-Encoding header field MUST treat the message as if the framing is faulty, even if a Content-Length is present, and close the connection after processing the message. 転送エンコードヘッダーフィールドを含むHTTP/1.0メッセージを受信するサーバーまたはクライアントは、コンテンツ長が存在していても、フレーミングが故障しているかのようにメッセージを扱う必要があり、メッセージを処理した後に接続を閉じます。

6.2. Content-Length

[ ] A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.送信者は、転送エンコードヘッダーフィールドを含むメッセージにコンテンツレングスヘッダーフィールドを送信してはなりません。

6.3. Message Body Length

[ ] 2. Any 2xx (Successful) response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes the header fields. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in such a message.2. 接続要求に対する2xx（成功）応答は、ヘッダーフィールドを終了する空の行の直後に接続がトンネルになることを意味します。クライアントは、そのようなメッセージで受信したコンテンツレングスまたは転送エンコードヘッダーフィールドを無視する必要があります。
[ ] 3. If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 11.2) or response splitting (Section 11.1) and ought to be handled as an error. An intermediary that chooses to forward the message MUST first remove the received Content-Length field and process the Transfer-Encoding (as described below) prior to forwarding the message downstream.3.メッセージがTransfer-EncodingヘッダーフィールドとContent-Lengthヘッダーフィールドの両方で受け取られた場合、Transfer-EncodingはContent-Length よりも優先される。そのようなメッセージは、リクエストの密輸(セクション11.2)または応答の分割(セクション11.1)の試みを示すかもしれず、エラーとして扱われるべきである。メッセージを転送(forward)することを選択した仲介エンティティは、メッセージをダウンストリームに転送(forward)する前に、まず受け取ったContent-Lengthフィールドを取り除き、(以下に述べるように) Transfer-Encodingを処理しなければならない[MUST]。
[ ] If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.リクエスト中にTransfer-Encodingヘッダーフィールドが存在し、チャンクされた転送(transfer)コード化が最終エンコーディングでない場合、メッセージボディの長さを確実に決定することはできない。
[ ] 5. If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error, unless the field value can be successfully parsed as a comma-separated list (Section 5.6.1 of [HTTP]), all values in the list are valid, and all values in the list are the same (in which case, the message is processed with that single value used as the Content-Length field value). If the unrecoverable error is in a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection. If it is in a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad Gateway) response to the client. If it is in a response message received by a user agent, the user agent MUST close the connection to the server and discard the received response.5. 転送エンコードなしでメッセージが受信され、コンテンツレングスのヘッダーフィールドが無効になった場合、メッセージフレーミングは無効であり、フィールド値をコンマ分離リストとして正常に解析できる場合を除き、受信者はそれを回復不可能なエラーとして扱う必要があります。（[http]のセクション5.6.1）、リスト内のすべての値は有効であり、リスト内のすべての値は同じです（この場合、メッセージはコンテンツレングスのフィールド値として使用される単一値で処理されます）。回復不可能なエラーがリクエストメッセージにある場合、サーバーは400（悪い要求）ステータスコードで応答し、接続を閉じる必要があります。プロキシによって受信された応答メッセージにある場合、プロキシはサーバーへの接続を閉じ、受信した応答を破棄し、クライアントに502（悪いゲートウェイ）応答を送信する必要があります。ユーザーエージェントが受信した応答メッセージに含まれている場合、ユーザーエージェントはサーバーへの接続を閉じて、受信した応答を破棄する必要があります。
[ ] 6. If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.6. 有効なコンテンツレングスヘッダーフィールドが転送エンコードなしで存在する場合、その小数値はオクテットの予想されるメッセージボディの長さを定義します。指定されたオクテットの数を受信する前に送信者が接続を閉じるか、受信者がタイムアウトした場合、受信者はメッセージが不完全で接続を閉じることを検討する必要があります。
[ ] A user agent that sends a request that contains a message body MUST send either a valid Content-Length header field or use the chunked transfer coding. A client MUST NOT use the chunked transfer coding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.メッセージ本文を含むリクエストを送信するユーザーエージェントは、有効なコンテンツレングスヘッダーフィールドを送信するか、チャンク転送コーディングを使用する必要があります。クライアントは、サーバーがHTTP/1.1（またはそれ以降）リクエストを処理することを知っていない限り、チャンク転送コーディングを使用してはなりません。このような知識は、特定のユーザー構成の形で、または以前に受信した応答のバージョンを覚えている可能性があります。
[ ] If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that data belongs as part of the prior message body, which might be the case if the prior message's Content-Length value is incorrect. A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.接続の最後のリクエストに対する最終的な応答が完全に受信され、読み取る追加データが残っている場合、ユーザーエージェントは残りのデータを破棄するか、そのデータが以前のメッセージ本文の一部として属するかどうかを判断しようとすることができます。事前のメッセージのコンテンツレングス値が正しくない場合。クライアントは、そのような動作が中毒をキャッシュすることに対して脆弱であるため、そのような追加データを個別の応答として処理、キャッシュ、または転送してはなりません。

7. Transfer Codings

7.1. Chunked Transfer Coding

[x] The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer section, and finally terminated by an empty line. チャンクサイズのフィールドは、オクテットのチャンクデータのサイズを示す一連の16進数です。チャンクされた転送コーディングは、ゼロのチャンクサイズのチャンクが受信され、おそらくトレーラーセクションが続き、最終的に空のラインで終了すると完了します。
[x] #177
[x] A recipient MUST be able to parse and decode the chunked transfer coding.受信者は、チャンク転送コーディングを解析およびデコードできる必要があります。
[x] HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation. Therefore, recipients MUST anticipate potentially large hexadecimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation.HTTP/1.1は、充電された応答のサイズを制限する手段を定義しません。これにより、中間者が応答全体をバッファリングすることを保証できます。さらに、非常に大きなチャンクサイズは、受信の実装で値が正確に表されない場合、オーバーフローまたは精度の損失を引き起こす可能性があります。したがって、受信者は、潜在的に大きな16進数を予測し、整数変換のオーバーフローまたは整数表現による精度の損失による解析エラーを防ぐ必要があります。
7.1.1. Chunk Extensions
[x] A recipient MUST ignore unrecognized chunk extensions. A server ought to limit the total length of chunk extensions received in a request to an amount reasonable for the services provided, in the same way that it applies length limitations and timeouts for other parts of a message, and generate an appropriate 4xx (Client Error) response if that amount is exceeded. 受信者は、認識されていないチャンク拡張機能を無視する必要があります。サーバーは、メッセージの他の部分に長さの制限とタイムアウトを適用し、適切な4XX（クライアントエラーを生成するのと同じように、提供されるサービスの合理的な金額にリクエストで受信されたチャンク拡張機能の総長を制限する必要があります（クライアントエラー）その量を超えた場合の応答。

7.1.2. Chunked Trailer Section 非実装

[ ] A recipient that removes the chunked coding from a message MAY selectively retain or discard the received trailer fields.
[ ] A recipient that retains a received trailer field MUST either store/ forward the trailer field separately from the received header fields or merge the received trailer field into the header section.
[ ] A recipient MUST NOT merge a received trailer field into the header section unless its corresponding header field definition explicitly permits and instructs how the trailer field value can be safely merged.

7.3. Transfer Coding Registry

[ ] The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at https://www.iana.org/assignments/http-parameters.「HTTP転送コーディングレジストリ」は、転送コーディング名の名前空間を定義します。https://www.iana.org/assignments/http-parametersに維持されています。

Registrations MUST include the following fields: 登録には、次のフィールドを含める必要があります。

* Name
* 名前
* Description
* 説明
* Pointer to specification text
* 仕様テキストへのポインタ

Names of transfer codings MUST NOT overlap with names of content codings (Section 8.4.1 of [HTTP]) unless the encoding transformation is identical, as is the case for the compression codings defined in Section 7.2. 転送コーディングの名前は、セクション7.2で定義されている圧縮コーディングの場合のように、エンコード変換が同一でない限り、コンテンツコーディングの名前（[http]のセクション8.4.1）と重複してはなりません。

[ ] Values to be added to this namespace require IETF Review (see Section 4.8 of [RFC8126]) and MUST conform to the purpose of transfer coding defined in this specification.

7.4. Negotiating Transfer Codings

[ ] A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.

Three examples of TE use are below.
米国の3つの例を以下に示します。

TE: deflate
TE:
TE: trailers, deflate;q=0.5

[ ] Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 7.6.1 of [HTTP]) in order to prevent the TE header field from being forwarded by intermediaries that do not support its semantics.TEヘッダーフィールドは即時接続にのみ適用されるため、TEの送信者は、TEヘッダーフィールドが存在するのを防ぐために、接続ヘッダーフィールド内に「TE」接続オプション（[HTTP]のセクション7.6.1）を送信する必要があります。そのセマンティクスをサポートしていない仲介者によって転送されます。

memo

8. Handling Incomplete Messages　不完全なメッセージの処理

[x] A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding a supposedly chunked transfer coding fails, MUST record the message as incomplete. Cache requirements for incomplete responses are defined in Section 3.3 of [CACHING].

9. Connection Management 接続管理

9.2. Associating a Response to a Request

[x] A client that has more than one outstanding request on a connection MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the first outstanding request that has not yet received a final (non-1xx) response.接続に複数の未解決のリクエストを持っているクライアントは、送信された注文の未解決のリクエストのリストを維持する必要があり、最終（非1xx）を受け取っていない最初の未解決のリクエストにその接続に関する各受信応答メッセージを関連付ける必要があります。応答。
[x] If a client receives data on a connection that doesn't have outstanding requests, the client MUST NOT consider that data to be a valid response; the client SHOULD close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded per Section 2.2).クライアントが未解決のリクエストを持たない接続に関するデータを受信した場合、クライアントはそのデータを有効な応答と見なしてはなりません。データが1つ以上のCRLFのみで構成されていない限り、メッセージの区切りが曖昧になるため、クライアントは接続を閉じる必要があります（セクション2.2に従って破棄できます）。

9.3. Persistence

HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. HTTP implementations SHOULD support persistent connections.
[ ] A client that does not support persistent connections MUST send the "close" connection option in every request message.永続的な接続をサポートしていないクライアントは、すべてのリクエストメッセージに「閉じる」接続オプションを送信する必要があります。
[x] A server that does not support persistent connections MUST send the "close" connection option in every response message that does not have a 1xx (Informational) status code.永続的な接続をサポートしないサーバーは、1xx（情報）ステータスコードがないすべての応答メッセージに「閉じる」接続オプションを送信する必要があります。 A client MAY send additional requests on a persistent connection until it sends or receives a "close" connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. クライアントは、「閉じる」接続オプションを送信または受信するか、「キープアライブ」接続オプションなしでHTTP/1.0応答を受信するまで、永続的な接続に追加のリクエストを送信できます。
[x] In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 6. A server MUST read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST read the entire response message body if it intends to reuse the same connection for a subsequent request.セクション6で説明されているように、接続に関するすべてのメッセージが自己定義のメッセージ長（つまり、接続の閉鎖によって定義されていないもの）がある必要があります。応答を送信した後の接続。それ以外の場合、永続的な接続に関する残りのデータは、次のリクエストとして誤解されます。同様に、クライアントは、後続のリクエストのために同じ接続を再利用する予定の場合、応答メッセージ本体全体を読み取る必要があります。
[x] A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Appendix C.2.2 for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).プロキシサーバーは、HTTP/1.0クライアントとの永続的な接続を維持してはなりません（多くのHTTP/1.0クライアントによって実装されたKEEP-ALIVEヘッダーフィールドの問題の情報と議論については、付録C.2.2を参照）。

9.3.2. Pipelining パイプライン

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response).

[ ] A server MAY process a sequence of pipelined requests in parallel if they all have safe methods (Section 9.2.1 of [HTTP]), but it MUST send the corresponding responses in the same order that the requests were received.
[ ] When retrying pipelined requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client MUST NOT pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset problem described in Section 9.6).

9.6. Tear-down

The "close" connection option is defined as a signal that the sender will close this connection after completion of the response. A sender SHOULD send a Connection header field (Section 7.6.1 of [HTTP]) containing the "close" connection option when it intends to close a connection. For example,Connection: close

[ ] A client that sends a "close" connection option MUST NOT send further requests on that connection (after the one containing the "close") and MUST close the connection after reading the final response message corresponding to this request.「閉じる」接続オプションを送信するクライアントは、その接続にさらに要求を送信してはなりません（「閉じる」を含む後）は、この要求に対応する最終応答メッセージを読んだ後に接続を閉じる必要があります。
[ ] A server that receives a "close" connection option MUST initiate closure of the connection (see below) after it sends the final response to the request that contained the "close" connection option. The server SHOULD send a "close" connection option in its final response on that connection. The server MUST NOT process any further requests received on that connection.「閉じる」接続オプションを受信するサーバーは、「閉じる」接続オプションを含むリクエストに最終的な応答を送信した後、接続の閉鎖を開始する必要があります（以下を参照）。サーバーは、その接続の最終応答で「閉じる」接続オプションを送信する必要があります。サーバーは、その接続で受信したリクエストを処理してはなりません。
[ ] A server that sends a "close" connection option MUST initiate closure of the connection (see below) after it sends the response containing the "close" connection option. The server MUST NOT process any further requests received on that connection.「閉じる」接続オプションを送信するサーバーは、「閉じる」接続オプションを含む応答を送信した後、接続の閉鎖を開始する必要があります（以下を参照）。サーバーは、その接続で受信したリクエストを処理してはなりません。
[ ] A client that receives a "close" connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the "close" connection option; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server.「閉じる」接続オプションを受信するクライアントは、「閉じる」接続オプションを含む応答メッセージを読んだ後、その接続の要求の送信を停止し、接続を閉じる必要があります。接続に追加のパイプラインリクエストが送信されていた場合、クライアントはサーバーによって処理されると想定してはなりません。

9.7. TLS Connection Initiation

Conceptually, HTTP/TLS is simply sending HTTP messages over a connection secured via TLS [TLS13].

[ ] All HTTP data MUST be sent as TLS "application data" but is otherwise treated like a normal connection for HTTP (including potential reuse as a persistent connection).すべてのHTTPデータは、TLS「アプリケーションデータ」として送信する必要がありますが、それ以外の場合はHTTPの通常の接続のように扱われます（潜在的な再利用を含む）。

9.8. TLS Connection Closure

[ ] Clients MUST send a closure alert before closing the connection. Clients that do not expect to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.クライアントは、接続を閉じる前に閉鎖アラートを送信する必要があります。これ以上のデータを受け取ることを期待していないクライアントは、サーバーのクロージャーアラートを待機せず、接続を閉じるだけで、サーバー側に不完全な近接を生成することを選択する場合があります。
[ ] Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers MAY close the connection after sending the closure alert, thus generating an incomplete close on the client side.サーバーは、接続を閉じる前にクライアントとの閉鎖アラートの交換を開始しようとする必要があります。サーバーは、クロージャーアラートを送信した後に接続を閉じる可能性があり、クライアント側に不完全なクローズを生成する場合があります。
10. Enclosing Messages as Data

10.1. Media Type message/http
[ ] The "message/http" 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. Because of the line length limitations, field values within "message/http" are allowed to use line folding (obs-fold), as described in Section 5.2, to convey the field value over multiple lines. A recipient of "message/http" data MUST replace any obsolete line folding with one or more SP characters when the message is consumed.「メッセージ/HTTP」メディアタイプを使用して、単一のHTTP要求または応答メッセージを囲むことができます。ラインの長さの制限のため、セクション5.2で説明されているように、「メッセージ/HTTP」内のフィールド値は、複数の行でフィールド値を伝えるために、ライン折りたたみ（倍数）を使用できます。「メッセージ/http」データの受信者は、メッセージが消費されたときに、時代遅れの線の折りたたみを1つ以上のSP文字に置き換える必要があります。
```
Type name:
message
Subtype name:
http
Required parameters:
N/A
Optional parameters:
version, msgtype
```

version: The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: only "7bit", "8bit", or "binary" are permitted Security considerations: see Section 11 Interoperability considerations: N/A Published specification: RFC 9112 (see Section 10.1). Applications that use this media type: N/A Fragment identifier considerations: N/A Additional information: Magic number(s): N/A Deprecated alias names for this type: N/A File extension(s): N/A Macintosh file type code(s): N/A Person and email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: N/A Author: See Authors' Addresses section. Change controller: IESG

soma0822 / webserv

RFC 9112 #112