[47] HTTP/2 の設定settingは、エンドポイントにおけるプロトコルの動作に関する引数を peer に共有する仕組みです。

仕様書

意味

[5] SETTINGS フレーム (フレーム型 0x4) は、通信に関わる引数の設定情報を伝達するものです >>4。またその返答acknowledgeにも使います >>4。

[6] SETTINGS の引数を設定settingともいいます >>4。

[7] 設定は、エンドポイントの性質を説明するものであり、折衝するものではありません。 両 peer は同じ引数の違う値を使うこともあります。 >>4

[27] なお設定の値や設定に依存した機能の挙動は、fingerprinting vector です >>31。

構文

[16] ストリーム識別子は、 0x0 でなければなりません >>4。 ストリームにのみ設定を適用することはできません。

[12] 次のフラグがあります。

[13] ACK フラグ (0x1 = 第0ビット)
設定されていれば、 peer の SETTINGS フレームを受信し適用したことを acknowledge することを表します。 >>4

[45] 他のフラグは 0 にしなければなりません。 受信者は無視しなければなりません。 >>44

width
8
  1. 1 ACK
  2. 1 0
  3. 1 0
  4. 1 0
  5. 1 0
  6. 1 0
  7. 1 0
  8. 1 0

[20] payload は、0個以上の引数の列です。各引数は、 符号無し16ビットの識別子identifier欄と、 符号無し32ビットの値value欄で構成されます。 >>4 いずれもネットワークバイト順です >>43。

  1. *
    1. 識別子
    2. 値

[14] ACK フラグが設定されている場合は、 payload は空でなければなりません >>4。

[39] フラグが設定されていなくても空でも構いません。通常は意味がありませんが、 接続序文や HTTP2-Settings: ヘッダーでは空であっても SETTINGS フレームが必須となっています。

文脈

[8] SETTINGS フレームは、接続の確立直後に両エンドポイントが接続序文の一部として送信しなければなりません >>37, >>4。

HTTP/2接続、HTTPS、接続序文も参照。

[38] Upgrade: h2c 要求メッセージは、 HTTP2-Settings: ヘッダーの値として SETTINGS フレームをちょうど1つ送信しなければなりません >>36。

[9] SETTINGS フレームは、 接続中必要に応じて送ることができます >>4。

設定 (引数)

[22] 次の標準の設定があります。実装は、これらの設定すべてに対応しなければなりません >>4。

[3] (新たな) 設定を拡張の折衝に使う場合、既定値は当該拡張を無効としなければなりません >>1。

[34] IANA登録簿 >>46 があります >>33。 次の設定が登録されています。

[35] 0xf000-0xffff は実験用に予約されています >>33。

[48] IANA登録簿は 0x0000 を RFC 7540 を出典に予約しています >>46。 しかし RFC 7540 にそのような規定は見当たりません。

[50] >>49 に JSON 形式の一覧データファイルがあります。
  • [49] data-web-defs/http-frames.txt at master · manakai/data-web-defs ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/http-frames.txt

処理

[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 上では) 接続エラーとなることがあります。 実際には黙って無視されるだけかもしれません。

各設定の項を参照。

[11] 設定は出現順に処理します。 >>4

[23] 設定の更新中に他のフレームを処理してはなりません >>4。

[24] すべての設定の処理を終えたら、直ちに ACK フラグを設定した SETTINGS フレームを送信しなければなりません >>4。

[40] 接続序文の一部である SETTINGS フレームでも必要です >>37。[41] 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 を送らないように見えます。

[55] それ以外で送りたくなる場面はあるのでしょうか。 実装が無駄に複雑になるだけの気がしますが。。。