プロトコルは受信者が不明なフレームタイプを持つフレームを受信した場合、無視することを要求しています。両エンドポイントはホップバイホップで新しいフレームタイプの使用をネゴシエートすることができます。それらのフレームはセッションの状態を変えることが許されておらず、フロー制御されません。

http2に拡張を許すかどうかはプロトコル策定中に賛成と反対の意見の間で揺れ動き長い時間議論されました。ドラフト12の後、振り子は再度振れ、拡張を許すことになりました。

拡張はプロトコルの一部ではなく、基本のプロトコル仕様とは別の文書で定義されます。この時点ですでに基本プロトコルに含める意図をもって2つのフレームタイプが議論されていましたが、おそらく最初の拡張となるでしょう。ここではこの2つのフレームを紹介します。というのはこれらはよく知られているということと、もともと”標準”フレームの扱いだったからです。

7.1. オルタナティブサービス

http2の普及が進むにつれ、HTTP 1.xの時よりもTCP接続がはるかに長く持続するだろうとする理由があります。クライアントは1接続で全て間に合わせなければならないので、その接続は潜在的にかなり長い間開かれている可能性があります。

これはHTTPロードバランサーに影響を与え、サイトがクライアントに別のホストに接続してほしいという状況が生まれる可能性があります。それは性能のためだけではなく、サイトがメンテナンスや似たような理由でダウンするときもそうです。

サーバーはそのような場合Alt-Svcヘッダー (またはhttp2のALTSVCフレーム)を送信し、クライアントにオルタナティブサービスについて伝えます。別のサービス、ホスト、ポート番号を使って、同じコンテンツへ別のルートでアクセスするのです。

クライアントはオルタナティブサービスに非同期的に接続を試行し、うまくいったときだけそれを使うようにします。

7.1.1. 日和見暗号化

Alt-Svcヘッダーによりサーバーはhttp://で配信しているコンテンツをTLS接続でも配信しているとクライアントに伝えることができます。​

これはそれなりに議論を生んだ機能です。このような接続は認証されたTLSではなく、”安全”だとはいえず、UIで鍵マークを使うことは出来ません。実際、ユーザーにこれは平文のHTTPではなく、日和見暗号だと伝えるすべはないため、一部の人々は強くこのアイデアに反対しています。

7.2. Blocked

このフレームは、http2のエンドポイントが送信可能なデータがあるがフロー制御によって送信できない時に一度だけ送信します。背景にあるアイデアは、あなたの実装がこのフレームを受信した場合、あなたの実装が間違っている、または帯域を使い切れていないということを知ることができるというものです。

このフレームを拡張として扱うため削除される前のドラフト12からの引用です:

”BLOCKEDフレームは実験のためこのドラフトに導入されました。実験結果が有意義なフィードバックを示さない場合、削除される可能性があります。”