[21] プッシュメッセージは、 プッシュ配信されるメッセージです。
[2] Web Push の定義では、 プッシュメッセージは、 アプリケーションサーバーから利用者エージェントへとプッシュサービスを介して送られるメッセージです。 >>1 1.1.
[22] Push API の定義では、 プッシュメッセージはアプリケーションサーバーから Webアプリケーションに送信されるデータです。 >>20
[6] プッシュメッセージは、それが送信された (受信した) こと自体が情報になります。 それに加えて、付随する情報がいくつかあります。
Last-ModifiedTTL:
HTTPヘッダーで有効期限を指定できます。
期限到来後、未配送のプッシュメッセージは捨てられます。
同時にプッシュメッセージ資源も削除されるかもしれません。
(アプリケーションサーバーが指定し、
プッシュサービスが適宜修正します。)Urgency:
HTTPヘッダーで緊急度を指定できます。
(アプリケーションサーバーが指定し、
プッシュサービスが保持します。)[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 は、
次のようにしなければなりません。
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
は、
プッシュメッセージのデータを表します。
サービスワーカー環境に晒されます
>>28。
SecureContext のみ利用可能です >>28。
PushMessageData のメンバー[31]
PushEvent インターフェイスの
data
属性の取得器 >>23 は、
次のようにしなければなりません。
[33]
PushEventInit 辞書の
data
メンバー >>23 は、
PushEvent
インターフェイスの
data
に対応します。値は
PushMessageDataInit とされています >>23
が、他に
null
もあり得るようです。
既定値は
null です。
[36]
PushEvent
インターフェイスのイベント構築手順群の
data
の処理は、
辞書とイベントについて、
次のようにします。
>>23
data が null でない場合、data
を、
新しい PushMessageData
に設定します。PushMessageDatadata
について実行した結果[34]
PushMessageDataInit
は、
BufferSource
または
USVString
に
typedef
されています。
>>23
[35] オブジェクトについて extract a byte sequence するには、 次のようにします。 >>28
[4] プッシュメッセージ資源は、 プッシュサービスにおいてプッシュメッセージを識別する資源です。 >>1 2.1. URL によって識別されます。
[50] プッシュサービスは、 アプリケーションサーバーの求めるプッシュメッセージの配送を受理したときプッシュメッセージ資源を作成し、 利用者エージェントがプッシュメッセージの受領肯定したときプッシュメッセージ資源を削除します。 >>1 2.1.
[51] Web Push Protocol 上プッシュメッセージ資源を能動的に操作することはできません。 次のように使われます。
GET 要求という形でプッシュメッセージ配送に使われます。GET 要求という形でプッシュメッセージ受領の伝達に使われます。[9]
両者は同じ URL の GET
でありながら、内容も意味も違います。
[17]
理論上、
server push の意味論的には、
プッシュメッセージ資源を直接 GET
することでも同じようにアクセスできるはずですが、
このような特殊な構造になっている以上、
server push 以外の方法で使うことは考えられていないのでしょう。
[10] プッシュメッセージは、
アプリケーションサーバーがプッシュサービスのプッシュ資源へと送信することで作成されます。
[8] プッシュメッセージは、
プッシュサービスから利用者エージェントへと、
プッシュメッセージ購読やプッシュメッセージ購読集合の要求に対する
server push で配送されます。
Webブラウザーは、
適切なサービスワーカーを起動し、
push
イベントによって配送します。
[55] プッシュサービスは、 受理したプッシュメッセージを配送のため保持します。 次の場合にプッシュメッセージは削除されます。
Last-Modified + TTL が現在時刻を超えた場合Topic: と重複した場合[11] 利用者エージェントは、 プッシュメッセージを最低1回は配送されたことを示す、 受領肯定を表明しなければなりません。 >>1 6.2.
[12]
利用者エージェントは、
プッシュメッセージ資源に
DELETE
要求を送らなければなりません
>>1 6.2.。
[16]
DELETE
に対してプッシュサービスが送るべき応答は、特に規定されていません。
200 や 204
が適当でしょうか。
DELETE が既に行われている場合などのエラー処理も特に規定がありません。
[14]
プッシュサービスは、
十分な時間内に肯定を受信しない場合、
未配送とみなします。
TTL: 到来まで配送を試み続けるべきです。
>>1 6.2.