仕様書

意味

[35] HTTP/2 server push は、 応答とそれに対応する「約束 (promised) 」要求を、 先にクライアントが開始した要求に関連付ける形でサーバーから予め送信 (push) するものです >>34。

[36] server push は、クライアントが元の要求に対する応答を完全に処理するために当該応答が必要になるであろうとわかっている場合に便利です >>34。

[55] server push は、意味的にはクライアントの要求にサーバーが応答を返す通常の場合と同じですが、 要求をクライアントではなくサーバーが (クライアントへと) PUSH_PROMISE フレームにより送信します >>34。

[52] クライアントは、 push できません >>34。

約束要求

[44] サーバーからクライアントへと送信する要求を、 約束要求 (promised request) といいます。

[39] 約束要求は、要求本体を含んではなりません >>34。

[56] PUSH_PROMISE フレーム (と CONTINUATION フレーム) が、要求の header block を含みます。 要求のヘッダーを妥当かつ完全に含まなければなりません。 >>34

[49] サーバーは、当該サーバーが権限を有する (authoritative) :authority 疑似ヘッダー値を含めなければなりません >>34。

[37] 約束要求は、キャッシュ可能でなければなりません >>34。

[38] 約束要求は、安全でなければなりません >>34。

[58] サーバーは、 :method 疑似ヘッダーに安全でキャッシュ可能な要求メソッドを指定しなければなりません >>34。

[61] サーバーは、約束された応答を参照するフレームを送信する前に、 PUSH_PROMISE フレームを送信するべきです。 これによりクライアントが PUSH_PROMISE フレームを送信する前に別途要求を発行することを防ぐことができます。 >>34

[71] 複数の著者の資源を提供するサーバーは、 他の著者の管轄下のはずの資源をプッシュできてしまわないようにしなければなりません >>70。

プッシュ応答

[48] 約束要求に続いてサーバーからクライアントへと送信する応答を、 プッシュ応答 (pushed response) といいます。

[65] サーバーは PUSH_PROMISE フレーム (と CONTINUATION フレーム) に続けて (同じストリームで) プッシュ応答を配送開始できます >>34。

文脈

[119] Webページは HTML文書から参照される CSS や JavaScript などいろいろなファイルの集合体として構成されますが、 その読み込みの最適化のため、 HTML文書の応答中に server push を使って他の構成ファイルが送信されることがあります。

[120] Web Push Protocol では、 プッシュメッセージ購読資源、 プッシュメッセージ購読集合資源、 受領証購読資源で server push が使われます。

処理

[60] クライアントは、約束要求に完全で妥当なヘッダーの集合が含まれていなければ、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[40] クライアントは、キャッシュ可能でない約束要求を受信したら、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[41] クライアントは、安全でない約束要求を受信したら、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[59] クライアントは、 :method 疑似ヘッダーに安全でない要求メソッドが指定されていれば、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[42] クライアントは、要求本体の存在を示した約束要求を受信したら、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[50] クライアントは、サーバーが権限を有する (authoritative) かプロキシであって対応する要求に関するプッシュ応答を提供するよう設定されていることを検証しなければなりません。 それ以外の値の :authority 疑似ヘッダーが含まれていたら、 ストリームエラー PROTOCOL_ERROR としなければなりません >>34。

[45] プッシュ応答は、キャッシュ可能なら、 クライアントの HTTPキャッシュに蓄積できます >>34。

[46] プッシュ応答は、ストリームが open である間、起源サーバーで成功裏に検証されたものとみなします >>34。

[47] プッシュ応答は、キャッシュ可能でなければ、 HTTPキャッシュに蓄積してはなりません。 別途応用に提供しても構いません。 >>34

[51] 中間器は、サーバーからの push をクライアントへと転送しないことにしても構いません。 またサーバーから送られてこなくても独自にクライアントに push しても構いません。 >>34

[66] クライアントは、 PUSH_PROMISE フレームを受信し、 プッシュ応答を受け入れることにしたら、 そのストリームが閉じられるまでの間、 その応答に対する要求を発行するべきではありません >>34。

[67] クライアントは、何らかの理由でプッシュ応答を受信したくない時や、 サーバーがプッシュ応答を送信し始めるまでの時間がかかりすぎている時は、 RST_STREAM フレームに誤り符号 CANCEL や REFUSED_STREAM を指定し、当該ストリーム識別子を指定して送信できます >>34。

[73] サーバーが authoritative でない応答をキャッシュしたり、 使ったりしてはなりません >>70。

[30] Firefox も Chrome も、異なる起源の約束要求を受信した時、 ストリームエラー REFUSED_STREAM とするようです。 2015-10-12T10:01:05.800Z

[106] Firefox も Chrome も、この検査を (PUSH_PROMISE の受信時でも fetch 時でもなく) 応答の受信時に行うようです。 2015-10-12T14:33:56.00Z

[111] 同じ :path の約束要求を受信したら、 Chrome はストリームエラー PROTOCOL_ERROR、 Firefox はストリームエラー INTERNAL_ERROR とします。この検査は PUSH_PROMISE 受信時点で行い、 約束ストリームに対して送信します。 2015-10-13T02:26:10.300Z

[77] クライアントは、 reserved (remote) 状態にあるストリームの数を制限するべきです。 超過したらストリームエラー ENHANCE_YOUR_CALM とできます。 >>76

PUSH_PROMISE フレーム

設定

[2] SETTINGS_ENABLE_PUSH (0x2) は、 server push を無効化するために使うことができます。 >>1

[5] 値 1 は、 server push を認めることを表します。これは初期値です。 >>1

[6] 値 0 は、 server push を認めないことを表します >>34。

[7] 1 と 0 以外の値は、接続エラー PROTOCOL_ERROR としなければなりません >>1。

[54] クライアントは、 SETTINGS_ENABLE_PUSH が 0 以外の値に設定されようとしたら、 拒絶して接続エラー PROTOCOL_ERROR としなければなりません >>34。

[102] 実際には Chrome も Firefox も、値の検査をしていないようです。 2015-10-12T03:20:51.100Z

[68] クライアントは、設定 SETTINGS_MAX_CONCURRENT_STREAMS によってサーバーが並行してプッシュできる応答の数を制限できます。 0 を設定することで、server push のためのストリームの作成を抑制できます。 ただし PUSH_PROMISE フレームの送信を禁止するものではありません。 >>34

fetch と server push

[92] Chrome や Firefox は、 fetch に当たり PUSH_PROMISE を受け取っていれば、新たに要求を送信せずにその応答を待つようです。 しかし fetch の呼び出し方法 (やタイミング?) によって別途要求を送信することもあります。 2015-10-12T10:15:29.700Z

歴史