[2] フレームは、HTTP/2接続中の通信の最小単位です。フレームはヘッダーと可変長のオクテット列で構成されます。 >>1
[51] フレームの型は、フレームの種類を表す8ビットの値です >>3。
[52] フレームの形式と意味はフレーム型によって指定されます。 >>3
[45] 0xf0
-0xff
は、実験用に予約されています >>43。
[62] 送信者は未知のフレーム型のフレームを送ってはならないと思われますし、 送る必要もないはずです。
[53] フレームの長さ欄は、 payload の長さを符号無し24ビット整数 (ネットワークバイト順 >>1) で表現したものです >>3。単位はバイトです。 フレームの長さは、本欄に示された payload の長さの値 (とフレームのヘッダーの 9 バイトの和) により決まります。
[6] payload の長さは、設定 SETTINGS_MAX_FRAME_SIZE
の値よりも大きな値としてはなりません >>3。
[32] 設定 SETTINGS_MAX_FRAME_SIZE
(0x5
)
は、送信者が受信する意志のある最大のフレームの payload
の長さをバイト単位で表します >>31, >>3。
[15] 本設定の値は、 214 以上、 224-1 以下でなければなりません >>3, >>31。
範囲外の値は、接続エラー PROTOCOL_ERROR
としなければなりません >>31。
[16] すべての実装は、 214 バイト以下の payload を扱うことができなければなりません >>3。
[67] Chrome も Firefox も、値域外の値が指定された時を含め、 完全に無視しているように見えます。少なくても接続エラーにはなりません。
[19] エンドポイントは、次の場合に FRAME_SIZE_ERROR
エラー符号を送信しなければなりません >>3。
[23] 接続全体の状態を変えてしまい得るフレームの長さのエラーは、 接続エラーとなければなりません >>3。これには次のものが含まれます。
[10] それ以外の場合は、ストリームエラーで良いものと思われます。
[39] SETTINGS_MAX_FRAME_SIZE
を超える値だとしても、
接続エラーでなくストリームエラーとする場合、
次のフレームを正しく処理できるよう、
指定された長さ分通常通り読む (読み飛ばす) 必要があります。
[40] Firefox は DATA
フレームであっても
SETTINGS_MAX_FRAME_SIZE
を超える長さの時、
接続エラー PROTOCOL_ERROR
とするようです。
更に大量のデータを受信している場合には GOAWAY
を送信せずすぐに接続を閉じるようです。
[42] Chrome は DATA
の SETTINGS_MAX_FRAME_SIZE
の検査をしないようです。
[64] Firefox も Chrome も、HEADERS
の payload は 218 までエラーとはしません。
218+1 以上のヘッダーを受信すると、 214 まで受信を待ちます。
その後 Firefox は接続エラー PROTOCOL_ERROR
、
Chrome は接続エラー FRAME_SIZE_ERROR
とします。ただしその後更にデータを受信した場合は、
GOAWAY
を送信せずに直ちに接続を閉じるようです
(閾値は payload のサイズが Chrome で 214、
Firefox で 215 弱のようです)。
[11] RST_STREAM
フレームや
WINDOW_UPDATE
フレームの長さのエラーも、
接続エラーとなります。
[34] FRAME_SIZE_ERROR
(0x6
) は、
非妥当なサイズのフレームを受信したことを示します >>13。
[56] フレームのフラグ群は、 boolean フラグ用の8ビットの欄です。 >>3
[57] 8つのビットごとに、フレーム型に依存 >>3 した意味が定義されているか、 未定義のままとされています。
[60] 次のフラグがあります。ただしすべてのフレーム型で定義されているわけではありませんし、 第0ビットはフレーム型により異なる意味が割り当てられています。
[8] 送信者は、フレーム型によりフラグ群の意味が定義されていない場合、 0 を設定しなければなりません >>3。
[9] 受信者は、フレーム型によりフラグ群の意味が定義されていない場合、 無視しなければなりません >>3。
[65] Chrome は未定義のフラグを受信したら、
接続エラー PROTOCOL_ERROR
とします。
Firefox は無視します。
[47] フレームは、ストリーム上のバイト列として送受信されます。
[48] SETTINGS
フレームは、 HTTP/1.1
HTTP2-Settings:
ヘッダー内に含まれることがあります。
[27] フレームの送受信は、ストリームの状態を変化させます。 状態によっては、受信したらエラーとしなければならないフレーム型もあります。
[58] 小さなフレームや payload が空のフレームは、
無駄な処理をさせるために濫用できます。
エンドポイントは利用状況を監視して制限するべきです。
接続エラー ENHANCE_YOUR_CALM
としても構いません。 >>59
[66] Chrome も Firefox も、フレームの途中まで受信した時に残りを受信するまでの特別なタイムアウトは用意していないように見えます。
Firefox は定期的に PING
を送信するので、それに応答がないことにより接続が閉じられます。
[36] Chrome も Firefox も、
FRAME_SIZE_ERROR
ではなく PROTOCOL_ERROR
を使っているようです。
[37] Chrome はフレームのヘッダー部分を読んだ時点でエラーを検査しているように見えます。 Firefox は payload まですべて読んでから検査しているように見えます。
[38] Chrome は SETTINGS_MAX_FRAME_SIZE
を超えていないかの検査をしていないように見えます。
[41] フレームのヘッダーの途中や payload として指定された長さに満たずに接続が閉じられた場合、
Firefox は (正常終了なら) GOAWAY
(NO_ERROR
) を送信し、
Chrome はそのまま、接続を閉じるようです。
どちらも要求はネットワークエラーになります。
[68] Firefox は接続序文で SETTINGS_MAX_FRAME_SIZE
に 214 を設定しますが、これは初期値と同じです。
[69] The ORIGIN HTTP/2 Frame () http://httpwg.org/http-extensions/origin-frame.html
[70] draft-hoffman-dns-in-existing-http2-00 - Running DNS in Existing HTTP/2 Connections () https://tools.ietf.org/html/draft-hoffman-dns-in-existing-http2-00
[71] 無職転生Ⅱ ~異世界行ったら本気だす~ 13話上映会 - 2024/4/11(木) 0:00開始 - ニコニコ生放送 () https://live.nicovideo.jp/watch/lv344746642