メインコンテンツまでスキップ

8. Expressing HTTP Semantics in HTTP/2 (HTTP/2でのHTTPセマンティクスの表現)

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

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

8.1. HTTP Message Framing (HTTPメッセージフレーム化)​

HTTPメッセージ（リクエストまたはレスポンス）は以下で構成されます:

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

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

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

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

シーケンスの最後のフレームは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リクエストまたはレスポンスは、以下のいずれかである場合、不正な形式 (malformed) です:

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

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

  • フィールド行名に大文字を含む場合、または

  • 無効なContent-Lengthフィールド値を含む場合。

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

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

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

8.1.1. Malformed Messages (不正な形式のメッセージ)​

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

8.2. HTTP Fields (HTTPフィールド)​

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

HTTP/2は、接続固有のフィールドを示すためにHTTP/1.1で定義されている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フィールド自体を削除する必要があることを意味します。そのような中間体は、Connectionフィールドで指定されていない場合でも、Keep-Alive、Proxy-Connection、Transfer-Encoding、Upgradeなどの他の接続固有のフィールドも削除すべきです (SHOULD)。

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

8.2.1. Field Validity (フィールドの有効性)​

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

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

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

8.2.2. Connection-Specific Header Fields (接続固有のヘッダーフィールド)​

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

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

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

より良い圧縮を可能にするために、Cookieヘッダーフィールドは、それぞれ1つ以上のCookieペアを持つ個別のヘッダーフィールドに分割できます (MAY)。解凍後に複数のCookieヘッダーフィールドがある場合、これらは、非HTTP/2コンテキスト（HTTP/1.1接続、または一般的なHTTPサーバーアプリケーションなど）に渡される前に、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 Control Data (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. Request Pseudo-Header Fields (リクエスト疑似ヘッダーフィールド)​

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の非推奨のユーザー情報サブコンポーネントを含んではなりません (MUST NOT)。

    HTTP/1.1リクエスト行を正確に再現できるようにするために、オリジン形式またはアスタリスク形式（[HTTP]のセクション3.2を参照）を持つHTTP/1.1リクエストから変換する場合、この疑似ヘッダーフィールドは省略しなければなりません (MUST)。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を参照））が含まれます。アスタリスク形式のリクエストには、:path疑似ヘッダーフィールドの値'*'が含まれます。

    この疑似ヘッダーフィールドは、"http"または"https" URIに対して空であってはなりません (MUST NOT)。パスコンポーネントを含まない"http"または"https" URIは、リクエストがアスタリスク形式で行われる場合を除き、'/'の値を含まなければならず (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）ステータスコード（[HTTP]のセクション15.5.1を参照）で応答すべきです (SHOULD)。

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

8.3.2. Response Pseudo-Header Fields (レスポンス疑似ヘッダーフィールド)​

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

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

8.4. Server Push (サーバープッシュ)​

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

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

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

8.4.1. Push Requests (プッシュリクエスト)​

サーバープッシュは、サーバーがリクエストに応答することと意味的に同等です。ただし、この場合、そのリクエストもサーバーによって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 Responses (プッシュレスポンス)​

約束されたストリームを参照する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. The CONNECT Method (CONNECTメソッド)​

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

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

CONNECTリクエストは以下の疑似ヘッダーフィールドを使用しなければなりません (MUST):

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

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

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

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

プロキシは、既知の禁止されているメッセージフィールド（たとえば、[HTTP]のセクション7.6.1で定義されているような接続固有のフィールド）を削除し、残りのリクエストヘッダーフィールドがサーバーへの接続上で変更されずに通過することを許可します。

CONNECTリクエスト後に受信される任意の2xx（成功）レスポンスは、プロキシが要求されたホストおよびポートへの接続を確立し、対応するストリームのブリッジを開始したことを示します。

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

トンネルが正常に確立された後、サーバーはトンネルを即座に閉じるために、トンネルストリーム上で単一のDATAフレーム（END_STREAMフラグセット付き）を送信しなければなりません (MUST)。クライアントは、いずれかのエンドポイントでトンネルを閉じた後、そのストリームをハーフクローズし、ピアからEND_STREAMフラグを受信した後にそのストリームを閉じるべきです (SHOULD)。

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

8.6. The Upgrade Header Field (Upgradeヘッダーフィールド)​

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

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

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

8.7. Request Reliability (リクエストの信頼性)​

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

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

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

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

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

8.8. Examples (例)​

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

8.8.1. Simple Request (単純なリクエスト)​

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. Simple Response (単純なレスポンス)​

単純な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. Complex Request (複雑なリクエスト)​

オプションのフィールドを持つ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. Response with Body (ボディ付きレスポンス)​

フィールドとレスポンスボディを含む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. Informational Responses (情報的レスポンス)​

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

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

:status = 100

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

{binary data}

第8章完了！

References​

  • [HTTP] RFC 9110
  • [COOKIES] RFC 6265
  • [COMPRESSION] RFC 7541
  • [URI] RFC 3986
  • [TLS13] RFC 8446
  • [ALT-SVC] RFC 7838
に最終更新