クライアント接続序文

接続序文 (HTTP)

[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.1HTTP/1.0サーバー中間器が以後のフレームを処理しようとしなくなるものが選ばれました >>2PRI は本目的のためのダミーの要求メソッドです >>13HTTP 以外のプロトコルへの 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 としなければなりませんpeerHTTP/2 では無いので、 GOAWAY フレームは省略しても構いません。 >>2

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

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

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

[19] ChromeFirefox接続序文の受信を待たずに最初の要求を送信します。 接続序文の特別なタイムアウトは無いようで、 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 を送信します。