[47] HTTP/2 の設定は、エンドポイントにおけるプロトコルの動作に関する引数を peer に共有する仕組みです。
[5] SETTINGS フレーム (フレーム型 0x4)
は、通信に関わる引数の設定情報を伝達するものです >>4。またその返答にも使います >>4。
[6] SETTINGS の引数を設定ともいいます >>4。
[7] 設定は、エンドポイントの性質を説明するものであり、折衝するものではありません。 両 peer は同じ引数の違う値を使うこともあります。 >>4
[27] なお設定の値や設定に依存した機能の挙動は、fingerprinting vector です >>31。
[16] ストリーム識別子は、 0x0 でなければなりません >>4。
ストリームにのみ設定を適用することはできません。
[45] 他のフラグは 0 にしなければなりません。 受信者は無視しなければなりません。 >>44
[20] payload は、0個以上の引数の列です。各引数は、 符号無し16ビットの識別子欄と、 符号無し32ビットの値欄で構成されます。 >>4 いずれもネットワークバイト順です >>43。
[8] SETTINGS フレームは、接続の確立直後に両エンドポイントが接続序文の一部として送信しなければなりません >>37, >>4。
[38] Upgrade: h2c 要求メッセージは、
HTTP2-Settings: ヘッダーの値として
SETTINGS フレームをちょうど1つ送信しなければなりません
>>36。
[22] 次の標準の設定があります。実装は、これらの設定すべてに対応しなければなりません
>>4。
[3] (新たな) 設定を拡張の折衝に使う場合、既定値は当該拡張を無効としなければなりません >>1。
[34] IANA登録簿 >>46 があります >>33。 次の設定が登録されています。
[35] 0xf000-0xffff は実験用に予約されています >>33。
[48] IANA登録簿は 0x0000 を RFC 7540 を出典に予約しています >>46。
しかし RFC 7540 にそのような規定は見当たりません。
[81] 受信者は、設定 SETTINGS_MAX_FRAME_SIZE
より長いなら、接続エラー FRAME_SIZE_ERROR としなければなりません
>>82。
[15] 受信者は、 SETTINGS フレームの ACK フラグが設定されていて、
payload の長さ欄の値が 0 でなければ、接続エラー FRAME_SIZE_ERROR
としなければなりません >>4。
[17] 受信者は、ストリーム識別子が 0x0 でなければ、
接続エラー PROTOCOL_ERROR
としなければなりません >>4。
[18] 受信者は、SETTINGS フレームの形式が誤っているか不完全なら、
接続エラー PROTOCOL_ERROR としなければなりません >>4。
[19] 受信者は、SETTINGS フレームの payload
が 6 の倍数でなければ、
接続エラー FRAME_SIZE_ERROR としなければなりません >>4。
[10] SETTINGS フレームの受信者は、
ACK フラグが設定されていなければ、
可能な限りすぐに指定された引数を適用しなければなりません >>4。
新しい値により、既存の値を置き換えます >>4。
[2] 未知の設定は、無視しなければなりません >>1, >>4。
[21] 設定によっては、指定できる値に制約があり、 それを満たさなければ (RFC 上では) 接続エラーとなることがあります。 実際には黙って無視されるだけかもしれません。
[23] 設定の更新中に他のフレームを処理してはなりません >>4。
[24] すべての設定の処理を終えたら、直ちに ACK フラグを設定した
SETTINGS フレームを送信しなければなりません >>4。
HTTP2-Settings: ヘッダーの SETTINGS
フレームに対しては、 Upgrade: h2c に対する
101 応答をもって暗示的な acknowledgement
とみなされるため、送信しなくて構いません。送信は禁止されていませんが、
送信すると次の接続序文の SETTINGS
フレームに対する acknowledgement と解釈されてしまうと思われます。[53] 未知の設定が指定された (そして無視された) 場合や、設定が1つも指定されなかった場合も、
ACK を送る必要があります。 (そうしないとどの SETTINGS
に対する ACK か相手にわからなくなります。)
[25] ACK フラグが設定された SETTINGS フレームを受信したら、
設定が適用されたことに依存できるようになります >>4。
[42] どの SETTINGS フレームに対する acknowledgement
かを明示する方法はありません。送信者は、送信したことを覚えておき、
どれが acknowledge されたか判断する確認する必要があります。
[26] 十分な時間内に acknowledgement を受信しなければ、
接続エラー SETTINGS_TIMEOUT (0x4)
としても構いません >>4, >>28。
[51] Chrome も Firefox も (接続序文も含め) そのようなタイムアウトは無いように見えます。
[52] SETTINGS を送信していないのに ACK 付き
SETTINGS を受信したときどうするべきなのかは明記されていませんが、
Chrome でも Firefox でも黙って無視されます。
[30] SETTINGS フレームは、
意味もなく引数を変更したり、未定義の引数を設定したり、
同じ引数を何度も変更したりして無駄な処理をさせるために濫用できます。
エンドポイントは利用状況を監視して制限するべきです。
接続エラー ENHANCE_YOUR_CALM としても構いません。 >>29
[32] SETTINGS フレームの返信によって peer までの遅延が測定されると、
プライバシー上問題となることもあるかしれません >>31。
[54] Chrome も Firefox も接続序文と ACK
以外では SETTINGS を送らないように見えます。
HTTP2-Settings:ヘッダーでは空であってもSETTINGSフレームが必須となっています。