[19] HTTP2-Settings: ヘッダーは、 Upgrade: h2c を指定した HTTP/1.1 over TCP から HTTP/2 over TCP への移行を求める要求において、 HTTP/2 SETTINGS フレームを指定するものです。

代替

[20] このヘッダーが広く実装されるかどうかは不明です。

Upgrade: h2c も参照。

[21] そもそも TLS を使わない HTTP は安全ではないので、 使うべきではありません。通常は HTTP/2 over HTTPS を使うべきです。 HTTPS では本ヘッダーは使いません。

仕様書

意味

[3] HTTP/2接続に関する引数を含むものです >>1。

[4] connection-specific header field です >>1。

構文

[5] 字句68です >>1。

[9] 値は、 SETTINGS フレームの payload を RFC 4648 base64url 符号化し詰めを省略したものです >>1。

文脈

[2] HTTP/1.1 から HTTP/2 への切り替えの要求は、 HTTP2-Settings: ヘッダーをちょうど1つだけ含まなければなりません >>1。

[10] Connection: にも HTTP2-Settings を指定しなければなりません >>1。

[6] サーバーは、送信してはなりません >>1。

[12] クライアントが Upgrade: h2c 以外の文脈で使ってはならないという規定は、なぜかありません。

[14] HTTP/1.0 で利用することは明確には禁止されていませんが、 HTTP/1.0 では Upgrade: は利用できないため、意味がありません。

[17] HTTP/2 では生成してはなりません >>1, >>16。

[15] HTTP/2 メッセージに HTTP2-Settings: ヘッダーを指定しても意味はありません。 SETTINGS フレームを使う必要があります。

処理

[8] サーバーは、 HTTP2-Settings: ヘッダーが複数あるか、 1つもなければ、HTTP/2 に切り替えてはなりません >>1。

[11] サーバーは、値を通常の SETTINGS フレームと同じように解釈します >>1。

[18] base64url 復号やフレーム解釈によりエラーが検出された場合にどうするべきなのかは不明です。 切り替えずに HTTP/1.1 で処理を続けるべきなのでしょうか。

[7] 詳しくは Upgrade: h2c を参照。

[22] HTTP/2 への切り替えを表す要求以外では無視するべきと思われますが、 RFC には明記されていません。

歴史

[24] HTTP/2 と共に導入されました。

[23] HTTP/2 プロトコルネゴシエーション方法と ATS での実装 - Yahoo! JAPAN Tech Blog ( 版) http://techblog.yahoo.co.jp/infrastructure/http2/ats_http2_pn/

ATS には現状 HTTP アップグレードメカニズムを使用した HTTP/2 へのアップグレードには対応しておらず、NPN もしくは ALPN によるプロトコルネゴシエーションのみサポートされている状態です。しかしながらアップグレード対応の為の実装作業はそれほど大掛かりな作業ではなく、http スキームからのネゴシエーション方法もサポートしておきたいため(本稿のためのネタ作りも兼ねて!)今回実装してパッチを送りました。