8. HTTP/2におけるHTTPセマンティクスの表現

HTTP/2は、現在のHTTPの使用と可能な限り互換性があるように設計されています。これは、アプリケーションの観点からは、プロトコルの機能がほとんど変更されていないことを意味します。これを達成するために、すべてのリクエストとレスポンスのセマンティクスは、HTTP/1.1 [HTTP]のメカニズムを通じて保持されますが、これらのセマンティクスを伝達する構文は変更されています。

したがって、HTTP [HTTP]、セマンティクスと構文、および[COOKIES]などの拡張の仕様と要件は、HTTP/2に適用されます。このセクションで説明されている制限と追加の要件は、HTTP/2の成功した実装に必要なもの、HTTPのワイヤーフォーマットに関連するもの、またはHTTP/2で追加の定義がない場合に曖昧さをもたらすものに限定されています。

8.1. HTTPメッセージのフレーミング

HTTPメッセージ（リクエストまたはレスポンス）は、次のもので構成されます：

1. レスポンスのみの場合、情報（1xx）HTTPレスポンスのメッセージヘッダーを含む0個以上のHEADERSフレーム（それぞれ0個以上のCONTINUATIONフレームが続く）（[HTTP]のセクション15を参照）、および/または

2. メッセージヘッダーを含む1つのHEADERSフレーム（0個以上のCONTINUATIONフレームが続く）（[HTTP]のセクション6.3を参照）、および

3. メッセージコンテンツを含む0個以上のDATAフレーム（[HTTP]のセクション6.4を参照）、および

4. オプションで、トレーラーパートフィールドセクションを含む1つのHEADERSフレーム（0個以上のCONTINUATIONフレームが続く）（[HTTP]のセクション6.5を参照）。

シーケンスの最後のフレームはEND_STREAMフラグを持ち、END_STREAMフラグを持つHEADERSフレームは、ヘッダーブロックの残りの部分を運ぶCONTINUATIONフレームが続くことができることに注意してください。他のフレーム（任意のストリームから）は、HEADERSフレームとそれに続く可能性のあるCONTINUATIONフレームの間に現れてはなりません（MUST NOT）。

HTTP/2は、メッセージコンテンツを運ぶためにDATAフレームを使用します。[CHUNKED]転送コーディング（[HTTP]のセクション7.1で定義）は、HTTP/2で使用してはなりません（MUST NOT）。

トレーラーフィールドは、フィールドセクションで運ばれます。セクション8.2を参照してください。トレーラーフィールドには定義されたフィールドセクション名がありません。すべてのトレーラーフィールドは、HTTP/2の同じフィールドセクションにエンコードされるためです。フィールド行の間に定義された順序はありません。セクション8.2.1を参照してください。最後に、トレーラーフィールドには疑似ヘッダーフィールドが含まれません（セクション8.3を参照）。

HTTPリクエストまたはレスポンスは、次のいずれかである場合、不正な形式です：

• 無効なフィールド名を持つフィールド行（[HTTP]のセクション5.1を参照）、無効なフィールド行値を持つフィールド行（[HTTP]のセクション5.5を参照）、またはそのコンテキストに表示することが許可されていない疑似ヘッダーフィールド（セクション8.3を参照）を含む場合、

• そのメッセージタイプに必要な疑似ヘッダーフィールドを省略している場合（セクション8.3を参照）、

• フィールド行名に大文字が含まれている場合、または

• 無効なContent-Lengthフィールド値が含まれている場合。

ストリームのエラー処理については、セクション8.1.1で説明されています。

メッセージの必須部分に加えて、PRIORITY情報がHEADERSフレームに存在する場合があります。詳細については、セクション5.3を参照してください。

無効なフィールドブロックを含むHEADERSフレームを受信すると、ストリームエラーになります（セクション5.4.2を参照）。

8.1.1. 不正な形式のメッセージ

不正な形式のメッセージは、それ以外は有効なフレームのシーケンスですが、禁止されたフィールドの存在、必要なフィールドの欠如、または無効なフィールド値のために無効です。不正な形式のリクエストまたはレスポンスを検出したピアは、ストリームエラーで応答しなければなりません（MUST）（セクション5.4.2を参照）。不正な形式のリクエストの場合、サーバーは、ストリームを閉じるかリセットする前にHTTPレスポンスを送信できます（MAY）。クライアントは、不正な形式のレスポンスを受け入れてはなりません（MUST NOT）。これらの要件は、いくつかの一般的な攻撃の種類から保護することを目的としていることに注意してください。実装をこれらの脆弱性にさらす可能性があるため、意図的に厳格です。

8.2. HTTPフィールド

HTTPフィールド名と値はオクテットのシーケンスであり、HTTP/1.xで使用されるのと同じエンコーディングで使用されます（[HTTP]のセクション5.1を参照）。ただし、フィールド名は、HTTP/2でエンコードする前に小文字に変換しなければなりません（MUST）。フィールド名に大文字を含むリクエストまたはレスポンスは、不正な形式として扱わなければなりません（MUST）（セクション8.1.1）。

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

これの唯一の例外は、TEヘッダーフィールドです。これは、HTTP/2リクエストに存在できます（MAY）。存在する場合、"trailers"以外の値を含んではなりません（MUST NOT）。

これは、HTTP/1.xメッセージをHTTP/2に変換する中継者は、Connectionフィールドによって指定されたすべてのフィールドを、Connectionフィールド自体とともに削除する必要があることを意味します。このような中継者は、Keep-Alive、Proxy-Connection、Transfer-Encoding、Upgradeなどの他の接続固有のフィールドも、Connectionフィールドによって指定されていなくても削除すべきです（SHOULD）。

|  注：HTTP/2は、意図的に別のプロトコルへのアップグレードをサポートしていません。
|  [セクション3](#3-starting-http2)で説明されているハンドシェイク方法は、代替プロトコルの
|  使用を交渉するのに十分であると考えられています。

8.2.1. フィールドの有効性

フィールド名は、[HTTP]のセクション5.1のルールに従って検証されますが、HTTP/2で表現する前に小文字に変換されます。

[COMPRESSION]を使用して圧縮されたフィールドセクションには、"optional whitespace"（OWS）プロダクションで定義される空白が含まれる場合があります。空白はフィールドの一部ではありません。解凍中、またはHTTP/1.1接続や一般的なHTTPサーバーアプリケーションなどの非HTTP/2コンテキストにメッセージを渡す前に削除しなければなりません（MUST）。

疑似ヘッダーフィールドの値は、セクション8.3で指定されています。

8.2.2. 接続固有のヘッダーフィールド

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

これの唯一の例外は、TEヘッダーフィールドです。これは、HTTP/2リクエストに存在できます（MAY）が、存在する場合、"trailers"以外の値を含んではなりません（MUST NOT）。

8.2.3. Cookieヘッダーフィールドの圧縮

Cookieヘッダーフィールド[COOKIES]は、セミコロン（";"）を使用してクッキーペア（または"クラム"）を区切ります。このヘッダーフィールドは、カンマ区切りのリストルール（[HTTP]のセクション5.3を参照）に従わないため、クッキーペアが効率的に圧縮されるのを妨げる可能性があります。Cookieヘッダーフィールドは、比較的大量のデータを含むことが多いため、これにより圧縮効率が大幅に低下する可能性があります。

より良い圧縮を可能にするために、Cookieヘッダーフィールドは、それぞれが1つ以上のクッキーペアを持つ別々のヘッダーフィールドに分割できます（MAY）。解凍後に複数のCookieヘッダーフィールドがある場合、これらは、HTTP/1.1接続や一般的なHTTPサーバーアプリケーションなどの非HTTP/2コンテキストに渡される前に、2オクテットの区切り文字0x3B、0x20（ASCII文字列"; "）を使用して単一のオクテット文字列に連結しなければなりません（MUST）。

したがって、次の2つのCookieヘッダーフィールドのリストは意味的に等価です。

cookie: a=b; c=d; e=f

cookie: a=b
cookie: c=d
cookie: e=f

8.3. HTTP制御データ

HTTP/2は、':'文字（ASCII 0x3a）で始まる特別な疑似ヘッダーフィールドを使用して、HTTP/1.xではメッセージの開始行で運ばれていたリクエストまたはレスポンスに関する情報を伝達します。疑似ヘッダーフィールドはHTTPフィールドではありません。エンドポイントは、このドキュメントで定義されているもの以外の疑似ヘッダーフィールドを生成してはなりません（MUST NOT）。

疑似ヘッダーフィールドは、HEADERSおよびPUSH_PROMISEフレームのフィールドセクションでのみ有効です。ただし、トレーラーフィールドを運ぶフィールドセクションには、疑似ヘッダーフィールドを含んではなりません（MUST NOT）。疑似ヘッダーフィールドを含むトレーラーパートフィールドセクションは、不正な形式として扱わなければなりません（MUST）（セクション8.1.1）。

疑似ヘッダーフィールドは、':'文字（ASCII 0x3a）で始まります。それらの名前は、このプレフィックスのみで構成されるフィールド名です。コロンは、フィールド名の一部ではありません。コロンは、フィールド名に使用されるトークンセットの一部ではありません（[HTTP]のセクション5.1を参照）。

すべての疑似ヘッダーフィールドは、すべての通常のフィールドの前に現れなければなりません（MUST）。通常のフィールドの後に現れる疑似ヘッダーフィールドを含むリクエストまたはレスポンスは、不正な形式として扱わなければなりません（MUST）（セクション8.1.1）。

次の疑似ヘッダーフィールドが定義されています：

8.3.1. リクエスト疑似ヘッダーフィールド

HTTP/2リクエストには、次の疑似ヘッダーフィールドが定義されています：

• :method疑似ヘッダーフィールドには、HTTPメソッド（[HTTP]のセクション9）が含まれます。

• :scheme疑似ヘッダーフィールドには、ターゲットURIのスキーム部分（[URI]のセクション3.1）が含まれます。

  :schemeは、"http"および"https"スキームURIに制限されません。プロキシまたはゲートウェイは、非HTTPスキームのリクエストを翻訳でき、HTTPを使用して非HTTPサービスと対話できるようにします。

  :scheme疑似ヘッダーフィールドを省略するCONNECTメソッドについては、セクション8.5を参照してください。

• :authority疑似ヘッダーフィールドには、ターゲットURIの権限部分（[URI]のセクション3.2）が含まれます。権限は、"http"または"https"スキームURIの非推奨のuserinfoサブコンポーネントを含んではなりません（MUST NOT）。

  HTTP/1.1リクエスト行を正確に再現できるようにするために、この疑似ヘッダーフィールドは、originまたはasterisk形式のリクエストターゲットを持つHTTP/1.1リクエストから翻訳する際に省略しなければなりません（MUST）（[HTTP]のセクション3.2を参照）。HTTP/2リクエストを直接生成するクライアントは、Hostフィールドの代わりに:authority疑似ヘッダーフィールドを使用しなければなりません（MUST）。HTTP/2リクエストをHTTP/1.1に変換する中継者は、リクエストにHostフィールドが存在しない場合、:authority疑似ヘッダーフィールドの値をコピーしてHostフィールドを作成しなければなりません（MUST）。

  サーバーは、:authority疑似ヘッダーフィールドとHostフィールドの両方を持つリクエストを含む場合、フィールド値が同一でない場合、そのリクエストを不正な形式として扱うべきです（SHOULD）。

• :path疑似ヘッダーフィールドには、ターゲットURIのパスとクエリ部分（absolute-pathプロダクションと、オプションで'?'文字に続くqueryプロダクション（[URI]のセクション3.3および3.4を参照））が含まれます。asterisk形式のリクエストには、:path疑似ヘッダーフィールドの値'*'が含まれます。

  この疑似ヘッダーフィールドは、"http"または"https" URIの場合、空であってはなりません（MUST NOT）。パスコンポーネントを含まない"http"または"https" URIは、リクエストがasterisk形式で行われない限り、'/'の値を含まなければなりません（MUST）。その場合、'*'の値を含まなければなりません（MUST）。

  :path疑似ヘッダーフィールドを省略するCONNECTメソッドについては、セクション8.5を参照してください。

すべてのHTTP/2リクエストは、CONNECTリクエスト（セクション8.5）でない限り、:methodおよび:scheme疑似ヘッダーフィールドの正確に1つの有効な値を含まなければなりません（MUST）。

:scheme疑似ヘッダーフィールドが権限を使用するスキームを識別する場合（[URI]のセクション3.2を参照）、リクエストターゲットを含まないHTTP/2リクエストは、:authorityフィールドまたはHostフィールドのいずれかを含まなければなりません（MUST）。これらのフィールドが欠落している場合、リクエストを受信するサーバーは、400（Bad Request）ステータスコードで応答すべきです（SHOULD）（[HTTP]のセクション15.5.1を参照）。

HTTP/2は、HTTP/1.1リクエスト行に含まれるバージョン識別子を運ぶ方法を定義していません。

8.3.2. レスポンス疑似ヘッダーフィールド

HTTP/2レスポンスには、HTTPステータスコードフィールドを運ぶ単一の:status疑似ヘッダーフィールドが定義されています（[HTTP]のセクション15を参照）。この疑似ヘッダーフィールドは、すべてのレスポンスに含まれなければなりません（MUST）。そうでない場合、レスポンスは不正な形式です（セクション8.1.1）。

HTTP/2は、HTTP/1.1ステータス行に含まれるバージョンまたは理由フレーズを運ぶ方法を定義していません。

8.4. サーバープッシュ

HTTP/2では、サーバーは、以前のクライアント開始のリクエストに関連して、レスポンスをクライアントに先制的に（または"プッシュ"）送信できます。これは、サーバーが、クライアントが元のリクエストへのレスポンスを完全に処理するためにこれらのレスポンスを利用可能にする必要があることを知っている場合に役立ちます。

プッシュされたレスポンスは、常にクライアントからの明示的なリクエストに関連付けられています。サーバーは、そのリクエストのストリーム上にPUSH_PROMISEフレームを送信します。PUSH_PROMISEフレームには、サーバーがリクエストに帰属させるリクエストフィールドの完全なセットを含むフィールドセクションが含まれています。

単一の接続で利用可能なストリーム識別子を除いて、サーバーによってプッシュできるレスポンスの数に制限はありません。ただし、クライアントは、SETTINGS_MAX_CONCURRENT_STREAMS設定を変更することにより、同時にプッシュされるストリームの数を制限できます。この値をゼロに設定すると、サーバーが必要なストリームを作成できなくなり、サーバープッシュが無効になります。これは、サーバーがPUSH_PROMISEフレームを送信することを妨げるものではありません。クライアントは、不要な約束されたストリームをリセットする必要があります。

8.4.1. プッシュリクエスト

サーバープッシュは、サーバーがリクエストに応答することと意味的に同等です。ただし、この場合、そのリクエストもサーバーによってPUSH_PROMISEフレームとして送信されます。

PUSH_PROMISEフレームには、サーバーがリクエストに帰属させるリクエストフィールドの完全なセットを含むフィールドセクションが含まれています。HTTP/2接続がTLS経由で開始された場合を除いて、リクエストボディを含むリクエストにレスポンスをプッシュすることはできません（[TLS13]を参照）。

プッシュされたリクエストは、キャッシュ可能でなければならず（MUST）（[HTTP]のセクション9.2.3を参照）、安全でなければならず（MUST）（[HTTP]のセクション9.2.1を参照）、リクエストコンテンツを含んではなりません（MUST NOT）。キャッシュ可能でない、安全でない、またはリクエストコンテンツを含むプッシュされたリクエストを受信するクライアントは、PROTOCOL_ERRORタイプのストリームエラー（セクション5.4.2）で約束されたストリームをリセットしなければなりません（MUST）。

プッシュされたリクエストフィールドとリクエスト疑似ヘッダーフィールドは、権威的でなければなりません（MUST）（セクション10.1を参照）。サーバーは、サーバーが権威的である:authority疑似ヘッダーフィールドに値を含めなければなりません（MUST）（セクション10.1を参照）。クライアントは、権威的でないプッシュされたリクエストを、PROTOCOL_ERRORタイプのストリームエラー（セクション5.4.2）として扱わなければなりません（MUST）。

クライアントは、約束されたストリーム識別子を参照して、サーバーにRST_STREAMを送信することにより、プッシュされたレスポンスを受信したくないことを通知できます。

サーバーは、クライアントが使用する、または他の方法で恩恵を受けると信じるレスポンスのみをプッシュすべきです（SHOULD）。サーバーは、可能なリクエストコンテンツ、リクエスト内のすべてのキャッシュフィールド、リクエストのメソッド、およびクライアントによって管理されることが知られている任意のコンテンツ（たとえば、以前のリクエストで受信したCookieに基づく）を考慮して、プッシュするものを決定する際に考慮すべきです（SHOULD）。

8.4.2. プッシュレスポンス

約束されたストリームを参照するPUSH_PROMISEフレームを送信した後、サーバーは、約束されたストリーム識別子を使用してストリーム上でプッシュされたレスポンスの配信を開始できます。サーバーは、約束されたストリーム識別子を使用して、HEADERSフレームを使用して初期レスポンスフィールドを伝達します。このストリームは、"half-closed (remote)"状態になります（セクション5.1）。サーバーは、競合状態を回避するために、PUSH_PROMISEフレームを送信する前に、プッシュを開始するレスポンスを送信すべきです（SHOULD）。

クライアントがPUSH_PROMISEフレームを受信し、プッシュされたレスポンスを受け入れることを選択すると、クライアントは、約束されたストリームが閉じられるまで、約束されたレスポンスのリクエストを発行すべきではありません（SHOULD NOT）。

クライアントが何らかの理由でサーバーからプッシュされたレスポンスを受信したくないと判断した場合、またはサーバーが約束されたレスポンスの送信を開始するのに時間がかかりすぎる場合、クライアントは、CANCELまたはREFUSED_STREAMコードのいずれかを使用し、プッシュされたストリーム識別子を参照して、RST_STREAMフレームを送信できます。

クライアントは、SETTINGS_MAX_CONCURRENT_STREAMS設定を使用して、サーバーが同時にプッシュできるレスポンスの数を制限できます。SETTINGS_MAX_CONCURRENT_STREAMSの値をゼロに通知すると、サーバーが必要なストリームを作成できなくなり、サーバープッシュが無効になります。これは、サーバーがPUSH_PROMISEフレームを送信することを禁止しません。クライアントは、不要な約束されたストリームをリセットする必要があります。

8.5. CONNECTメソッド

HTTP/1.xでは、疑似メソッドCONNECT（[HTTP]のセクション9.3.6）は、HTTP接続をリモートホストへのトンネルに変換するために使用されます。CONNECTは、主にHTTPプロキシで使用され、"https"リソースと対話するためにオリジンサーバーとのTLSセッションを確立します。

HTTP/2では、CONNECTメソッドは、同様の目的でリモートホスト上にトンネルを確立するために使用されます。

CONNECTリクエストは、次の疑似ヘッダーフィールドを使用しなければなりません（MUST）：

• :method疑似ヘッダーフィールドは、"CONNECT"に設定されます。
• :authority疑似ヘッダーフィールドには、接続先のホストとポートが含まれます（CONNECTリクエストのrequest-targetのauthority-formに相当します。[HTTP]のセクション3.2を参照）。

:schemeおよび:path疑似ヘッダーフィールドは省略しなければなりません（MUST）。

CONNECTリクエストは、Content-LengthまたはTransfer-Encodingヘッダーフィールドを含んではなりません（MUST NOT）。これらのフィールドを含むCONNECTリクエストは、不正な形式です（セクション8.1.1）。

CONNECTリクエストを運ぶストリームは、HTTPリクエストまたはレスポンスを伝達するためには使用されません。成功したCONNECTレスポンスは、ストリームがトンネルになったことをクライアントに通知するために使用されます。このストリームは、END_STREAMフラグを持つDATAフレームを受信しても閉じられません。CONNECTリクエストストリームは、END_STREAMフラグを持つDATAフレームを受信しても閉じられません。

プロキシは、接続固有であることが知られているすべてのヘッダーフィールド（[HTTP]のセクション7.6.1で定義されているものなど）を削除し、残りのリクエストヘッダーフィールドをサーバーへの接続上で変更せずに通過させます。

CONNECTリクエストの後に受信された任意の2xx（Successful）レスポンスは、プロキシが要求されたホストとポートへの接続を確立し、対応するストリームのトンネリングに切り替えたことを示します。

他の成功したレスポンスの場合、トンネルは作成されません。

成功したトンネルが確立された後、サーバーは、トンネルストリーム上で単一のDATAフレーム（END_STREAMフラグが設定されている）を送信して、トンネルをすぐに閉じなければなりません（MUST）。クライアントは、トンネルを閉じた後、いずれかのエンドポイントでストリームを半分閉じ、ピアからEND_STREAMフラグを受信した後、ストリームを閉じるべきです（SHOULD）。

TCP接続エラーは、エラーコードを持つRST_STREAMフレームを使用して、いずれかのエンドポイントによって通知されます。プロキシは、受信したエラーコードを、CONNECTリクエストを正常に完了できなかったストリームエラー（セクション5.4.2）の兆候として扱います。対応して、プロキシがCONNECTリクエストストリームを表すTCP接続でエラーを検出した場合、同じ方法でクライアントに信号を送信します。

8.6. Upgradeヘッダーフィールド

HTTP/2は、101（Switching Protocols）情報ステータスコード（[HTTP]のセクション15.2.2）をサポートしていません。

Upgradeヘッダーフィールドのセマンティクスは、アップグレード先のプロトコルに固有です。直接接続のUpgradeフィールド（セクション9.1.1）は、次のホップにのみ適用されます。したがって、UpgradeフィールドはHTTP/2には適用されません。

HTTP/2接続上で別のプロトコルにアップグレードしたい実装は、[ALT-SVC]を使用すべきです（SHOULD）。

8.7. リクエストの信頼性

一般に、HTTPクライアントは、エラーが発生したときに、エラーの性質を判断する手段がないため、非べき等リクエストを再試行できません。エラーの前にサーバー処理が発生した可能性があり、リクエストが再試行された場合に望ましくない効果をもたらす可能性があります。

サーバーがアプリケーション処理を実行せずにリクエストストリームを拒否した場合、リクエストは別の接続で再試行しても安全であると見なすことができます。サーバーは、RST_STREAMフレーム上のREFUSED_STREAMエラーコード（セクション7）を使用してこれを示すことができます。

サーバーは、アプリケーション処理を実行した後、REFUSED_STREAMエラーコードを使用してはなりません（MUST NOT）。これは、REFUSED_STREAMを使用すると、サーバーがリクエストに対して処理を実行しなかったことを示し、再試行しても安全であるためです。サーバーによって何らかの方法で処理されたリクエストには、別のエラーコードを使用しなければなりません（MUST）。

クライアントは、リクエストがべき等でない場合でも、REFUSED_STREAMを使用して拒否されたリクエストを再試行できます。ただし、クライアントがそのようなリクエストを再試行することを選択した場合、サーバーがリクエストを拒否する前に処理した可能性があると仮定しなければなりません（MUST）。クライアントがべき等でないリクエストを再試行した場合、サーバーが再試行されたリクエストを検出できるように、後続のリクエストにインジケーターを含めるべきです（SHOULD）。

キャッシュ不可能なコンテンツを含むPUSH_PROMISEリクエストは、再試行できません。セクション8.4.1で説明されているように、キャッシュ不可能または安全でないプッシュされたリクエストは許可されません。

8.8. 例

このセクションでは、HTTP/1.1リクエストとレスポンスを、同等のHTTP/2リクエストとレスポンスの図とともに示します。HTTP/2リクエストとレスポンスは、HTTP/2フレームレイヤーの上に示されていない圧縮されたヘッダーセクションを使用します。

8.8.1. シンプルなリクエスト

HTTP/1.1 GETリクエストには、リクエストフィールド、メソッド、およびリクエストターゲットが含まれます。

GET /resource HTTP/1.1
Host: example.org
Accept: image/jpeg

同じリクエストは、疑似ヘッダーフィールドを使用して表現され、HTTP/2のHEADERSフレームのフィールドセクションとして送信されます：

:method = GET
:scheme = https
:path = /resource
:authority = example.org
accept = image/jpeg

8.8.2. シンプルなレスポンス

シンプルなHTTP/1.1レスポンスには、ステータスコード、レスポンスフィールド、およびレスポンスコンテンツが含まれます：

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 123

{binary data}

HTTP/2では、ステータスコードは疑似ヘッダーフィールドを使用して表現されます：

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

8.8.3. 複雑なリクエスト

オプションのフィールドを持つHTTP/1.1 POSTリクエスト：

POST /resource HTTP/1.1
Host: example.org
Content-Type: image/jpeg
Content-Length: 123

{binary data}

同じHTTP/2リクエスト：

:method = POST
:scheme = https
:path = /resource
:authority = example.org
content-type = image/jpeg
content-length = 123

{binary data}

8.8.4. ボディを持つレスポンス

フィールドとレスポンスボディを含むHTTP/1.1レスポンス：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

HTTP/2では、フィールドセクションとDATAフレームを使用します：

:status = 200
content-type = text/html; charset=utf-8
content-length = 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

8.8.5. 情報レスポンス

HTTP/2は、[HTTP]のセクション15で定義されているように、HEADERSフレームを使用して送信される情報（1xx）レスポンスをサポートします。

たとえば、100（Continue）レスポンスは、最終レスポンスの前に送信できます：

:status = 100

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

---

第8章完了！

参考文献

• [HTTP] RFC 9110
• [COOKIES] RFC 6265
• [COMPRESSION] RFC 7541
• [URI] RFC 3986
• [TLS13] RFC 8446
• [ALT-SVC] RFC 7838