代替

[52] この方法が広く実装されるかどうかは不明です。

[14] 通常は HTTPS (HTTP/2 over TLS) を使うことが期待されています。 HTTPS では Upgrade: h2c は使いません。

[15] そもそも TLS のない HTTP は安全ではないので、使うべきではありません。 相互運用性のため、実装は Upgrade: h2c に対応するべきでもありません。

仕様書

構文

[50] クライアントは、 http: URL にアクセスする場合、 HTTP/1.1 要求の Upgrade: ヘッダーに、 h2c と指定します >>47。

[53] その場合、HTTP2-Settings: ヘッダーをちょうど1つ指定しなければなりません >>47。

文脈

[3] クライアントは TLS 上の HTTP で Upgrade: h2c を指定してはならないと思われます。

処理

[57] サーバーは、HTTP/2 に対応していれば、 101 応答を返します。その末尾の空行の直後から HTTP/2 フレームを送信できます。 >>47

[56] サーバーは、 HTTP/2 に対応していなければ、 Upgrade: を無視して通常通り HTTP/1.1 で応答を返すことになります。

[61] サーバーは、 TLS 上の HTTP なら Upgrade: h2c を無視しなければならないと考えられます。

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

[63] サーバーは、HTTP/2 に切り替える場合、 HTTP2-Settings: ヘッダーの値を通常の SETTINGS フレームと同じように解釈します >>47。

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

[2] 101 応答が暗示的な acknowledgement となるため、 明示的な acknowledgement の SETTINGS フレームは不要です。 >>47

[58] HTTP/2 に切り替えた場合、サーバーが最初に送るフレームは、 SETTINGS フレームの server connection preface でなければなりません >>47。

[59] クライアントは、101 応答を受信したら、 SETTINGS フレームを含む connection preface を送信しなければなりません >>47。

[7] 切り替えた場合、サーバーは、次のストリームを作成します >>47。

[8] 切り替えた場合、クライアントは、次のストリームを作成します。

[60] 切り替えた場合、サーバーは切り替え前の HTTP/1.1 要求に応答しなければなりません。 ストリーム識別子は、 1 とします。 >>47

メモ

[10] TLS のない素の TCP 上の HTTP は、現在では危険と考えられています。 Webブラウザー開発者やWeb標準の開発者の間では、 HTTPS でない HTTP における新機能の導入を不適切とみなす流れが10年代中頃に固まってきています。

[11] IETF は本機能を HTTP/2 仕様の一部に含めていますが、 Webブラウザーが実装するのかどうか、Webブラウザーが対応しないとしたら Webサーバーが実装するのかどうかには、疑問が持たれています。