メッセージ

プッシュメッセージ

[21] プッシュメッセージ (push message) は、 プッシュ配信されるメッセージです。

仕様書

意味

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

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

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

状態

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

[38] プッシュメッセージ
Last-Modified
TTL元期となる、 プッシュサービスプッシュメッセージを受信した日時です。 (プッシュサービスが保持します。)
有効期限
プッシュメッセージには、 必ず有効期限があります。 アプリケーションサーバーは、 TTL: HTTPヘッダーで有効期限を指定できます。 期限到来後、未配送のプッシュメッセージは捨てられます。 同時にプッシュメッセージ資源も削除されるかもしれません。 (アプリケーションサーバーが指定し、 プッシュサービスが適宜修正します。)
緊急度
アプリケーションサーバーは、 Urgency: HTTPヘッダーで緊急度を指定できます。 (アプリケーションサーバーが指定し、 プッシュサービスが保持します。)
データ
(アプリケーションサーバー利用者エージェントは暗号化されたデータを送受信しますが、 元のデータを知り得ます。 プッシュサービスは暗号化されたデータのみ知り得ます。 Webブラウザー上のアプリケーションは元のデータのみ見ます。)
プッシュメッセージ資源URL
(プッシュサービスが決定し、 アプリケーションサーバー利用者エージェントが知り得ます。)

データ

[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 は、 次のようにしなければなりません

  1. [26] SameObject: プッシュメッセージpayload暗号化に使える内容符号化FrozenArray<DOMString> を返します >>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 は、 プッシュメッセージデータを表します。 サービスワーカー環境晒されます >>28SecureContext のみ利用可能です >>28

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

[29] PushMessageDataメンバー

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

  1. [32] 文脈オブジェクトdata を返します >>23

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

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

  1. [37] 辞書datanull でない場合、
    1. [41] イベントdata を、 新しい PushMessageData に設定します。
      [42] PushMessageData
      バイト列
      extract a byte sequence辞書data について実行した結果

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

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

  1. [18] オブジェクトBufferSource の場合、
    1. [19] オブジェクトの内容の複製を返します。
  2. [20] オブジェクトUSVString の場合、
    1. [21] オブジェクトUTF-8符号化した結果を返します。

プッシュメッセージ資源

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

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

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

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

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

送信

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

受信

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

受領

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

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

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

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

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

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

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

メモ