仕様書

構文

[4] フレームは、9バイトのヘッダーと、 可変長のpayload で構成されます >>3。

[5] フレームのヘッダーは、次の欄で構成されます >>3。

フレーム型

[51] フレームの型 (Type) は、フレームの種類を表す8ビットの値です >>3。

[52] フレームの形式と意味はフレーム型によって指定されます。 >>3

[46] 次のフレーム型があります。

[45] 0xf0-0xff は、実験用に予約されています >>43。

[44] IANA登録簿 >>63 があります >>43。

[62] 送信者は未知のフレーム型のフレームを送ってはならないと思われますし、 送る必要もないはずです。

[7] 受信者は、未知のフレーム型のフレームを無視し、捨てなければなりません >>3, >>29。

payload の長さ

[53] フレームの長さ (Length) 欄は、 payload の長さを符号無し24ビット整数 (ネットワークバイト順 >>1) で表現したものです >>3。単位はバイトです。 フレームの長さは、本欄に示された payload の長さの値 (とフレームのヘッダーの 9 バイトの和) により決まります。

[54] payload の長さは、 0 以上の値です。

[6] payload の長さは、設定 SETTINGS_MAX_FRAME_SIZE の値よりも大きな値としてはなりません >>3。

[32] 設定 SETTINGS_MAX_FRAME_SIZE (0x5) は、送信者が受信する意志のある最大のフレームの payload の長さをバイト単位で表します >>31, >>3。

[33] 本設定の初期値は 2¹⁴ です >>31。

[15] 本設定の値は、 2¹⁴ 以上、 2²⁴-1 以下でなければなりません >>3, >>31。 範囲外の値は、接続エラー PROTOCOL_ERROR としなければなりません >>31。

[16] すべての実装は、 2¹⁴ バイト以下の payload を扱うことができなければなりません >>3。

[67] Chrome も Firefox も、値域外の値が指定された時を含め、 完全に無視しているように見えます。少なくても接続エラーにはなりません。 2015-10-12T03:09:09.400Z

[19] エンドポイントは、次の場合に FRAME_SIZE_ERROR エラー符号を送信しなければなりません >>3。

[23] 接続全体の状態を変えてしまい得るフレームの長さのエラーは、 接続エラーとなければなりません >>3。これには次のものが含まれます。

[10] それ以外の場合は、ストリームエラーで良いものと思われます。

[39] SETTINGS_MAX_FRAME_SIZE を超える値だとしても、 接続エラーでなくストリームエラーとする場合、 次のフレームを正しく処理できるよう、 指定された長さ分通常通り読む (読み飛ばす) 必要があります。

[40] Firefox は DATA フレームであっても SETTINGS_MAX_FRAME_SIZE を超える長さの時、 接続エラー PROTOCOL_ERROR とするようです。 更に大量のデータを受信している場合には GOAWAY を送信せずすぐに接続を閉じるようです。 2015-09-28T07:17:58.500Z

[42] Chrome は DATA の SETTINGS_MAX_FRAME_SIZE の検査をしないようです。 2015-10-10T08:13:47.000Z

[64] Firefox も Chrome も、HEADERS の payload は 2¹⁸ までエラーとはしません。 2¹⁸+1 以上のヘッダーを受信すると、 2¹⁴ まで受信を待ちます。 その後 Firefox は接続エラー PROTOCOL_ERROR、 Chrome は接続エラー FRAME_SIZE_ERROR とします。ただしその後更にデータを受信した場合は、 GOAWAY を送信せずに直ちに接続を閉じるようです (閾値は payload のサイズが Chrome で 2¹⁴、 Firefox で 2¹⁵ 弱のようです)。 2015-10-11T03:31:21.100Z

[11] RST_STREAM フレームや WINDOW_UPDATE フレームの長さのエラーも、 接続エラーとなります。

[34] FRAME_SIZE_ERROR (0x6) は、 非妥当なサイズのフレームを受信したことを示します >>13。

[49] 実際のデータの長さより長い payload の長さが指定された時にどうするべきかは不明です。

フラグ

[56] フレームのフラグ群 (Flags) は、 boolean フラグ用の8ビットの欄です。 >>3

[57] 8つのビットごとに、フレーム型に依存 >>3 した意味が定義されているか、 未定義のままとされています。

[60] 次のフラグがあります。ただしすべてのフレーム型で定義されているわけではありませんし、 第0ビットはフレーム型により異なる意味が割り当てられています。

[8] 送信者は、フレーム型によりフラグ群の意味が定義されていない場合、 0 を設定しなければなりません >>3。

[9] 受信者は、フレーム型によりフラグ群の意味が定義されていない場合、 無視しなければなりません >>3。

[65] Chrome は未定義のフラグを受信したら、 接続エラー PROTOCOL_ERROR とします。 Firefox は無視します。 2015-10-11T09:24:05.700Z

文脈

[47] フレームは、ストリーム上のバイト列として送受信されます。

[48] SETTINGS フレームは、 HTTP/1.1 HTTP2-Settings: ヘッダー内に含まれることがあります。

処理

[27] フレームの送受信は、ストリームの状態を変化させます。 状態によっては、受信したらエラーとしなければならないフレーム型もあります。

[28] フレームの処理は、フレーム型によって異なります。

[58] 小さなフレームや payload が空のフレームは、 無駄な処理をさせるために濫用できます。 エンドポイントは利用状況を監視して制限するべきです。 接続エラー ENHANCE_YOUR_CALM としても構いません。 >>59

[66] Chrome も Firefox も、フレームの途中まで受信した時に残りを受信するまでの特別なタイムアウトは用意していないように見えます。 Firefox は定期的に PING を送信するので、それに応答がないことにより接続が閉じられます。 2015-10-11T12:00:44.600Z

実装

[36] Chrome も Firefox も、 FRAME_SIZE_ERROR ではなく PROTOCOL_ERROR を使っているようです。 2015-09-28T07:03:22.200Z

[37] Chrome はフレームのヘッダー部分を読んだ時点でエラーを検査しているように見えます。 Firefox は payload まですべて読んでから検査しているように見えます。 2015-09-28T07:04:19.400Z

[38] Chrome は SETTINGS_MAX_FRAME_SIZE を超えていないかの検査をしていないように見えます。 2015-09-28T07:10:39.100Z

[41] フレームのヘッダーの途中や payload として指定された長さに満たずに接続が閉じられた場合、 Firefox は (正常終了なら) GOAWAY (NO_ERROR) を送信し、 Chrome はそのまま、接続を閉じるようです。 どちらも要求はネットワークエラーになります。 2015-09-28T09:44:16.300Z

[68] Firefox は接続序文で SETTINGS_MAX_FRAME_SIZE に 2¹⁴ を設定しますが、これは初期値と同じです。2015-10-20T08:18:08.200Z

[69] The ORIGIN HTTP/2 Frame (2016-12-24 19:55:06 +09:00) http://httpwg.org/http-extensions/origin-frame.html

[70] draft-hoffman-dns-in-existing-http2-00 - Running DNS in Existing HTTP/2 Connections (2017-04-11 17:24:40 +09:00) https://tools.ietf.org/html/draft-hoffman-dns-in-existing-http2-00

[71] 無職転生Ⅱ ~異世界行ったら本気だす~ 13話上映会 - 2024/4/11(木) 0:00開始 - ニコニコ生放送 (2024-04-15 13:58:22 +09:00) https://live.nicovideo.jp/watch/lv344746642