仕様書

アプリケーションサーバーからプッシュサービスへ

プッシュメッセージの送信

プッシュサービスから利用者エージェントへ

[48] 利用者エージェントは、 プッシュメッセージ購読とプッシュメッセージ購読集合の両方がある場合、 プッシュメッセージ購読集合を使ってプッシュメッセージを監視するべきです。 >>2 6.1.

[30] 利用者エージェントは、 プッシュメッセージ購読資源やプッシュメッセージ購読集合に対し、 GET 要求を送信して新しいプッシュメッセージの配送を要求します。 >>2 6., 6.1.

[38] 利用者エージェントは、 要求に Urgency: ヘッダーを指定できます。 Urgency:

[43] 利用者エージェントは、 Prefer: ヘッダーに waitPrefer: wait を値 0 で指定 (Prefer: wait=0) して、 即座にプッシュメッセージを送信するように求めることができます。 >>2 6., 6.1.

[39] プッシュサービスは Urgency: ヘッダーを処理しなければなりません。 Urgency:

[53] 対象のプッシュメッセージ購読またはプッシュメッセージ購読集合が満期となった場合、 404 応答を返さなければなりません。 >>2 7.3., 7.3.1.

[31] プッシュサービスは、 要求に対して応答しません。 HTTP/2 server push によってプッシュメッセージの内容を送信します。 >>2 6., 6.1.

[40] プッシュサービスは、プッシュメッセージごとに、 PUSH_PROMISE で GET 要求を利用者エージェントに送信します。 この GET 要求は、 プッシュメッセージ資源を取得するものです。 >>2 6., 6.1.

[41] それに対する応答は、 HTTPヘッダーで、 プッシュメッセージ購読に対応するプッシュ資源の URL を、 リンク関係型 urn:ietf:params:push で示すべきです。 >>2 6. プッシュメッセージ購読集合では、 示さなければなりません。 >>2 6.1. Link: ヘッダーに指定できます。 これを使ってプッシュメッセージ購読を区別できます。

[42] その応答本体には、 アプリケーションサーバーがプッシュ資源に送信した直近の要求の実体本体を指定します。 >>2 6., 6.1. (と規定されていますが、直近のというのは意味がよくわかりません。 当該プッシュメッセージを送るべきでしょう。)

[44] プッシュサービスは、 要求の Prefer: ヘッダーで waitPrefer: wait が 0 に設定されていた場合、 未配送のプッシュメッセージをすべて server push しなければなりません。 >>2 6., 6.1.

[45] プッシュサービスは、 204 応答を送信し、 server push を送信しないことで、 プッシュメッセージの不存在を示すことができます。 >>2 6., 6.1.

[46] このような規定の理由は名言されていませんが、 wait=0Prefer: wait が指定されていない限り、 プッシュサービスはプッシュメッセージ送信のタイミングを調整してよいということと思われます。

[47] 特に明言されていないので、 204 応答を返しても、そのままストリームを残し (END_STREAM を送信せず) 随時 server push してもよいとみられます。

[49] 仕様書では明文規定がありませんが、 例示によると、 プッシュサービスは適当なタイミングで最後に 200 応答を送りストリームを閉じてよいようです。 >>2 6., 6.1.

[58] 並行送信数を利用者エージェントは SETTINGS_MAX_CONCURRENT_STREAMS で指定することができ、 プッシュサービスはこれに従い抑制できます。 >>2 7.5.

[121] 利用者エージェントは、受信したプッシュメッセージについて、 適用されるオプション指定との整合性を検査するべきです。 PushSubscriptionOptions

利用者エージェントからサービスワーカーへ

[23] プッシュメッセージは、 プッシュ購読に関連付けられた活性ワーカーに配送されます。 (サービスワーカーが動作中でなければ、起動されます。) >>20

[6] 利用者エージェントは、 プッシュ購読プッシュ購読からプッシュメッセージプッシュメッセージを受信したら、 次のようにしなければなりません >>5。

  1. [7] 登録を、 プッシュ購読のサービスワーカー登録に設定します。
  2. [8] 登録が null の場合、
    1. [9] ここで停止します。
  3. [10] データを、 null に設定します。
  4. [11] プッシュメッセージが payload を持つ場合、
    1. [12] 平文を、 プッシュメッセージの payload をプッシュ購読について aes128gcm 復号した結果に設定します。
    2. [13] 平文が失敗の場合、
      1. [14] プッシュメッセージについて受領肯定します。 プッシュメッセージ資源
      2. [15] ここで停止します。

        [16] プッシュメッセージは捨てられます。 pushonpush を発火してはなりません。

    3. [17] データを、新しい PushMessageData に設定します。
      [18] PushMessageData
      バイト群bytes (PushMessageData)
      平文
  5. [19] fire a functional event します。
    イベント型
    pushonpush
    イベントインターフェイス
    PushEvent
    イベント対象
    登録
    dataPushMessageData
    データ
    extended lifetime promises がすべて解決された後の処理
    1. [21] すべてが成功裏に解決されていた場合、
      1. [22] プッシュメッセージを受領肯定します。 プッシュメッセージ資源
    2. [24] それ以外の場合、
      1. [25] プッシュメッセージと同じものが既に何度も配送されていて拒絶されていた場合、
        1. [26] プッシュメッセージを受領肯定します。

          [27] この場合、配送に失敗したにも関わらず、 成功したと通知されることになります。 何度も無限に再送されるのを防ぐためです。 それ以前に何度か拒絶されるのを許容するべきです。 最低3回は認めることが推奨recommendされます。

[161] ServiceWorkerGlobalScope インターフェイスの onpush 属性は、 イベントハンドラーIDL属性です。 >>160

[162] pushonpush イベントは、 プッシュ購読がプッシュメッセージを受信したことを示します。 >>160

[1] PushEvent インターフェイスは、 ExtendableEvent を継承しており、 サービスワーカー環境に晒されます。 SecureContext でのみ利用可能です。 PushEventInit 辞書は、 PushEvent に対応する辞書で、 ExtendableEventInit を継承しています。 >>160

[4] PushEvent インターフェイスメンバー、PushEventInit 辞書メンバー

[3] PushEvent コンストラクターは、 イベントコンストラクターですが、 dataPushMessageData 属性の処理があります。 >>160

メモ