HTTP/2の改定版仕様(RFC9113)の変更点について

2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。

作業中のドキュメントは「http2bis」として公開されている。

現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。

HTTPセマンティクス仕様を参照

もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。

それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。

セマンティクス側の変更点について以前書いた記事を参照ください。

asnokaze.hatenablog.com

TLS 1.3 への対応

もともとのHTTP/2の仕様は、TLS 1.3が出る前に標準化されました。その後、RFC8740「Using TLS 1.3 with HTTP/2」としてHTTP/2においてTLS1.3を使う場合の仕様が記述されています。

今回の改訂版は、RFC8740を取り込みつつ、TLS 1.3の使い方について言及しています

  • RFC8740に則り、post-handshake authenticationの禁止される
  • NewSessionTicketおよびKeyUpdateはHTTP/2に影響がないので、そのまま使用できる
  • RFC8470 に準じていれば、TLS 1.3 の 0-RTT Early DataでHTTPリクエストを送信出来る

RFC7540で定義される優先度制御の廃止

もともとHTTP/2で定義された依存関係を指定する優先度制御方式は、複雑すぎるということで廃止されました。以前紹介した、新しいHTTP優先度制御方式の使用が推奨されます。
asnokaze.hatenablog.com

改訂版では、具体的な優先度制御に関する記述が削除されました。ただし、既存のHTTP/2実装と互換性を維持するために、PRIORITYフレームやHEADERSフレームのフォーマットは変更はありません。既存のPRIORITYフレームを受信した場合は単純に破棄されます。

アップグレードを廃止

もともとの仕様では、HTTP/1.1でつないでから、その通信をHTTP/2にアップグレードする手順が定義されていました。ほぼ使われていないため、この方式は廃止されました。

フィールドのバリデーションを厳密に行う

ヘッダなどのフィールドにおいて、どのような文字が許容されるか、検証項目がより厳密になりました。

HTTP/2からHTTP/1.1に通信を中継するリバースプロキシの実装で、いくつかの脆弱性が見つかったため、より厳密に言及されるようになりました。

基本的には実装上の脆弱性ですが、具体的な攻撃手法は、「HTTP/2: The Sequel is Always Worse | PortSwigger Research」などを参照ください。

Experimental Useを開放

Experimental Useとして予約されていた拡張フレームタイプ値・SETTINGSパラメータ値を開放

Hostヘッダと:authority疑似ヘッダが一致すること

Hostヘッダと:authority疑似ヘッダが必ず一致することが必須となりました。

これも、HTTP/2からHTTP/1.1にプロキシする場合に、曖昧な部分があったため、厳密化されました