仕様書

意味

[2] Web Push の定義では、 プッシュメッセージpush messageは、 アプリケーションサーバーから利用者エージェントへとプッシュサービスを介して送られるメッセージです。 >>1 1.1.

[22] Push API の定義では、 プッシュメッセージpush messageはアプリケーションサーバーから Webアプリケーションに送信されるデータです。 >>20

[3] RFC 8030 がただ「message」とのみ書いているときでも、多くはプッシュメッセージとみられます。

状態

[6] プッシュメッセージは、それが送信された (受信した) こと自体が情報になります。 それに加えて、付随する情報がいくつかあります。

データ

[7] プッシュメッセージにはデータを含めることができます。 データは含めても含めなくても構いません。 プッシュメッセージを受信したという事実により、 その事由や利用者に提示するべき事項などは他の手段で取得すればいいので、 データは省略したり、最低限に抑えたりできるのです。 (Chrome の古い実装では、 データを含めることができませんでした。)

[39] データは、 プッシュメッセージの本質的な内容たる形態と、 それを転送用に暗号化した形態の2種類があります。 そのどちらも、関係する各仕様書は data、content、payload、 (HTTPメッセージの) body のような呼び方を混在させていて、 明瞭さを欠きます。

[40] データはアプリケーションサーバー → (プッシュエンドポイント) → プッシュサービス → (プッシュメッセージ購読資源) → Webブラウザー本体 → (PushEvent) → サービスワーカーと転送されますが、 このうちアプリケーションサーバーから Webブラウザー本体までは、暗号化された状態で移動します。 PushEvent でアプリケーションに提示される状態で解読済みの形に戻ります。

[5] データは HTTPメッセージの本体として転送されます。 Web Push Protocol 単体ではこの本体に具体的な制約を規定していません。 応用は、 末端対末端で機密性、 一貫性、 データ起源認証を提供する機構を用いなければならない >>1 8.1. とだけ定められています。

[43] Push API は、 利用者エージェントが aes128gcm に対応しなければならない、 互換性のため以前の I-D で定義されていた版にも対応して構わない、 と規定しています >>24。 (古い版への対応は、いずれ廃止される想定とみられます。) 利用者エージェントへの要件という形を採っていますが、 アプリケーションサーバーもこれに従う他選択肢はありません。

[25] PushManager インターフェイスの supportedContentEncodings 属性 >>24 は、 次のようにしなければなりません。

[44] データに付随して転送される HTTPヘッダーがプッシュメッセージの一部を構成するのか、 RFC は明言していません。 例示には Content-Type: text/plain; ... が常に示されていて、これがデータの形式を表すようにもみえます。 一方で Push API ではこの情報は使われませんし、 Push API が扱うデータはバイト列であって文字列ではないので、 この例示はあまり現実の利用に近いものでもありません。 実際上 HTTPヘッダーはプッシュメッセージを構成しないとみるべきでしょう。

[45] プッシュメッセージのデータの (転送用ではない) 本質的な内容は、 アプリケーション依存の任意のバイト列です。

[46] 理論上任意の長さのバイト列を扱えないこともないとされていますが、 プロトコルによって相互運用性が保証される長さ制限があって、 現実的にはその範囲に収める必要があります。 つまりデータは、 0 バイト以上、3993 バイト以下のバイト列でなければなりません。

[47] データが表すものは、テキストでも JSON でも画像でも、 何でも構いません。

[48] アプリケーションサーバーは、 データを暗号化してプッシュサービスに送信することになります。 その手順はプッシュメッセージの送信に使うライブラリーなどにより異なります。

[49] Webブラウザー上のアプリケーションは、 Webブラウザーのプッシュメッセージの受信処理によって解読されたデータを PushEvent から受け取ることになります。 データは PushMessageData オブジェクトとして表されます。

[27] PushMessageData インターフェイス >>28 は、 プッシュメッセージのデータを表します。 サービスワーカー環境に晒されます >>28。 SecureContext のみ利用可能です >>28。

[30] 状態としてバイト群を持ちます。

[31] PushEvent インターフェイスの data 属性の取得器 >>23 は、 次のようにしなければなりません。

[33] PushEventInit 辞書の data メンバー >>23 は、 PushEvent インターフェイスの data に対応します。値は PushMessageDataInit とされています >>23 が、他に null もあり得るようです。 既定値は null です。

[36] PushEvent インターフェイスのイベント構築手順群の data の処理は、 辞書とイベントについて、 次のようにします。 >>23

[34] PushMessageDataInit は、 BufferSource または USVString に typedef されています。 >>23

[35] オブジェクトについて extract a byte sequence するには、 次のようにします。 >>28

プッシュメッセージ資源

[4] プッシュメッセージ資源push message resourceは、 プッシュサービスにおいてプッシュメッセージを識別する資源です。 >>1 2.1. URL によって識別されます。

[50] プッシュサービスは、 アプリケーションサーバーの求めるプッシュメッセージの配送を受理したときプッシュメッセージ資源を作成し、 利用者エージェントがプッシュメッセージの受領肯定したときプッシュメッセージ資源を削除します。 >>1 2.1.

[51] Web Push Protocol 上プッシュメッセージ資源を能動的に操作することはできません。 次のように使われます。

• [52] プッシュメッセージの受信で、 server push される GET 要求という形でプッシュメッセージ配送に使われます。
• [53] プッシュメッセージの配送確認で、 server push される GET 要求という形でプッシュメッセージ受領の伝達に使われます。
  • [54] それとの照合のため、プッシュ資源の応答に URL が示されます。

[9] 両者は同じ URL の GET でありながら、内容も意味も違います。

[17] 理論上、 server push の意味論的には、 プッシュメッセージ資源を直接 GET することでも同じようにアクセスできるはずですが、 このような特殊な構造になっている以上、 server push 以外の方法で使うことは考えられていないのでしょう。

送信

[10] プッシュメッセージは、 アプリケーションサーバーがプッシュサービスのプッシュ資源へと送信することで作成されます。 プッシュメッセージの送信

受信

[8] プッシュメッセージは、 プッシュサービスから利用者エージェントへと、 プッシュメッセージ購読やプッシュメッセージ購読集合の要求に対する server push で配送されます。 Webブラウザーは、 適切なサービスワーカーを起動し、 push イベントによって配送します。 プッシュメッセージの受信

受領

[55] プッシュサービスは、 受理したプッシュメッセージを配送のため保持します。 次の場合にプッシュメッセージは削除されます。

• [56] 利用者エージェントへの配送確認ができた場合
• [57] Last-Modified + TTL が現在時刻を超えた場合
• [59] 新しいプッシュメッセージの Topic: と重複した場合
• [58] その他プッシュサービスが配送を断念せざるを得ない場合

[11] 利用者エージェントは、 プッシュメッセージを最低1回は配送されたことを示す、 受領肯定を表明しなければなりません。 >>1 6.2.

[12] 利用者エージェントは、 プッシュメッセージ資源に DELETE 要求を送らなければなりません >>1 6.2.。

[16] DELETE に対してプッシュサービスが送るべき応答は、特に規定されていません。 200 や 204 が適当でしょうか。 DELETE が既に行われている場合などのエラー処理も特に規定がありません。

[14] プッシュサービスは、 十分な時間内に肯定を受信しない場合、 未配送とみなします。 TTL: 到来まで配送を試み続けるべきです。 >>1 6.2.

[15] プッシュサービスは、 それ以前でも事情に鑑み適宜再配送を中断して構いません。 >>1 6.2.

[13] 受領されたかどうか、 プッシュサービスは受領証購読に適宜通知する必要があります。

メモ