[1] 接続序文connection prefaceは、 HTTP/2接続の最初に送信するバイト列です。

仕様書

意味

[4] クライアントとサーバーは、使っているプロトコルの最終確認と HTTP/2接続の初期設定の確立のため、接続序文を送信する必要があります >>2。

構文

[5] クライアント接続序文は、次の24バイトの列です >>2。

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

[6] これは、 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n を表しています >>2。 大部分の HTTP/1.1 や HTTP/1.0 のサーバーや中間器が以後のフレームを処理しようとしなくなるものが選ばれました >>2。 PRI は本目的のためのダミーの要求メソッドです >>13。 HTTP 以外のプロトコルへの cross-protocol attack を防ぐものではありません >>12。[14] なお WebSocket は、 WebSocket データを HTTPメッセージと解釈する壊れた中間器への対処のため、クライアントからのフレームをマスクすることにしています。 HTTP/2 はこの問題に対処していません >>2。ということは HTTP/2 over TCP は利用環境によっては脆弱かもしれません。

[7] クライアントはこの直後に SETTINGS フレームを送信しなければなりません >>2。 このフレームは空でも構いません >>2。

[10] クライアントは、サーバー接続序文を待たずに次のフレームを送り始めても構いません。 しかしサーバーの SETTINGS フレームには期待されるクライアントの動作が指定されているかもしれません。その受信後は、 それに従うことが期待されます。 >>2

[8] サーバー接続序文は、 SETTINGS フレームです。 このフレームは空でも構いません >>2。

文脈

[3] HTTP/2接続の最初にクライアントとサーバーがそれぞれ送信します >>15。

詳しくは HTTP/2接続や HTTPS を参照。

[16] クライアント接続序文とサーバー接続序文は、互いの到着を待たずに送信できます。

処理

[11] 妥当でない接続序文を受信したら、接続エラー PROTOCOL_ERROR としなければなりません。 peer が HTTP/2 では無いので、 GOAWAY フレームは省略しても構いません。 >>2

[9] peer から接続序文の一部として送信された SETTINGS フレームを受信したら、自身の接続序文を送信した後、 acknowledge しなければなりません >>2。

[17] Chrome でも Firefox でも、接続序文の SETTINGS として受信するフレームは ACK フラグが設定されていてもいなくても良いようです。

[18] 接続序文についてエラーがあった時、接続エラー PROTOCOL_ERROR とするようです。 GOAWAY フレームは送られないことが多いようですが、 既知フレームのように見えてエラーの時は送られるようです。しかしその条件は Firefox と Chrome で一致していないようです。

[19] Chrome も Firefox も接続序文の受信を待たずに最初の要求を送信します。 接続序文の特別なタイムアウトは無いようで、 Firefox は定期的な PING の送信に返答がなければ接続エラー INTERNAL_ERROR とします。

実装

[20] Firefox は、 SETTINGS_INITIAL_WINDOW_SIZE = 131072 と SETTINGS_MAX_FRAME_SIZE = 16384 = 214 (= 初期値) を送信します。

[21] Chrome は、 SETTINGS_MAX_CONCURRENT_STREAMS = 1000 と SETTINGS_INITIAL_WINDOW_SIZE = 6291456 を送信します。