仕様書

処理

[6] PushManager の subscribe メソッドは、 次のようにしなければなりません。 >>5

  1. [12] オプション群を、 第1引数を省略可能な PushSubscriptionOptionsInit 辞書として解釈した結果に設定します。
  2. [7] 約束を、 新しい約束に設定します。
  3. [8] 約束を返します。

[9] 非同期的に、次のようにしなければなりません。 >>5

  1. [10] 現在設定群オブジェクトが secure context でない場合、
    1. [11] 約束を、 SecurityError DOMException で拒絶し、 ここで停止します。
  2. [3] オプション群について、 applicationServerKey の正規化を実行します。 例外が投げられた場合、 約束を、 その例外で拒絶し、 ここで停止します。 applicationServerKey [4] 仕様書通りだと入力が直接編集されますが、実際そうなっているのかどうか?
  3. [21] プッシュサービスが公開鍵を必須とする場合 プッシュサービス であって、 オプション群の applicationServerKey が null の場合 >>5, >>13、
    1. [22] 約束を、 NotSupportedError DOMException で拒絶し、 ここで停止します。
  4. [23] 登録を、 文脈オブジェクトのサービスワーカー登録に設定します。
  5. [24] 登録の活性ワーカーが null の場合、
    1. [25] 約束を、 InvalidStateError DOMException で拒絶し、 ここで停止します。
  6. [26] permission を、 オプション群とこれがサービスワーカーからの呼び出しか否かについて、 permission を尋ねた結果に設定します。 permission 非同期的に待ちます。
  7. [27] permission が拒否の場合、
    1. [28] 約束を、 NotAllowedError DOMException で拒絶し、 ここで停止します。
  8. [40] 当該サービスワーカーがプッシュ購読を持つ場合、
    1. [29] 購読を、 当該サービスワーカーのプッシュ購読に設定します。 非同期的に待ちます。

      [35] 仕様書に明記されていませんが、 プッシュサービスへの fetch が想定されているようです。

    2. [30] 購読がエラーの場合、
      1. [31] 約束を、 AbortError DOMException で拒絶し、 ここで停止します。
      2. [32] 購読の options とオプション群の属性を比較します。 BufferSource は、等価性を比較します。 異なりがある場合、
        1. [33] 約束を、 InvalidStateError DOMException で拒絶し、 ここで停止します。
    3. [34] 約束を、 購読で解決します。
  9. [41] それ以外の場合、
    1. [36] 購読を、 オプション群についてプッシュ購読を作成した結果に設定します。 非同期的に待ちます。
    2. [37] 購読がエラーの場合、
      1. [38] 約束を、 AbortError DOMException で拒絶し、 ここで停止します。
    3. [39] 約束を、 購読で解決します。

[43] PushManager インターフェイスの getSubscription メソッドは、 次のようにしなければなりません。 >>42

  1. [44] 約束を、 新しい約束に設定します。
  2. [45] 約束を返します。

[46] 非同期的に、次のようにしなければなりません。 >>42

  1. [47] 当該サービスワーカーがプッシュ購読を持つ場合、
    1. [50] 購読を、 当該サービスワーカーのプッシュ購読に設定します。 非同期的に待ちます。

      [51] 仕様書に明記されていませんが、 プッシュサービスへの fetch が想定されているようです。

    2. [52] 購読がエラーの場合、
      1. [53] 約束を、 AbortError DOMException で拒絶し、 ここで停止します。
    3. [54] 約束を、 購読で解決します。
  2. [48] それ以外の場合、
    1. [49] 約束を、 null で解決します。

[81] 利用者エージェントは、 プッシュ購読の作成create a push subscriptionを、 PushSubscriptionOptions オプション群について、 次のようにしなければなりません。 >>73

  1. [83] プッシュ購読を、 新しいプッシュ購読に設定します。
    options
    オプション群の複製辞書の複製
  2. [80] プッシュ購読について、 aes128gcm のプッシュ購読作成時の手順を実行します。
  3. [86] プッシュ購読とオプション群の applicationServerKey について、 プッシュサービス資源を実行します。 非同期的に結果を待ちます。

    [111] 仕様書に明記がないですが、 fecth なので失敗することがあります。

  4. [87] プッシュ購読を返します。

[110] subscribe や更新プッシュ購読の更新から呼び出されます。

[56] プッシュサービス資源の URL の決定については、 プッシュサービスの発見を参照。

[57] 利用者エージェントは、いつでも新しいプッシュメッセージ購読を作成できなければなりません。 >>1 8.2.

[58] 利用者エージェントは、 新しいプッシュメッセージ購読を作成する際、 プッシュサービス資源に POST 要求を送信します。 >>1 4.

[16] 利用者エージェントは、 以前の要求に対する応答でプッシュメッセージ購読集合が指定されていたら、 要求にリンク関係型 urn:ietf:params:push:set でこれを指定するべきです。 >>1 4. Link: HTTPヘッダーで記述できます。

[17] 利用者エージェントは、 プッシュメッセージ購読の寿命の間、 プッシュメッセージを集約して受信することができないなら、 プッシュメッセージ購読集合を省略して構いません。 利用者エージェントが他のプッシュメッセージ受信者のかわりにプッシュメッセージ購読を監視するような場合に、 その必要があるかもしれません。 >>1 4.1.

[71] 利用者エージェントは、 VAPID で制限されたプッシュメッセージ購読を作成したい場合、 公開鍵を指定します。 Content-Type: は MIME型 application/webpush-options+json、 要求本体は RFC 7159 JSONオブジェクトとします。 その vapid の値は、 公開鍵を X9.62 uncompressed form で RFC 7515 base64url 符号化したものとします。 >>27

[70] プッシュサービス資源は、 プッシュメッセージ購読を作成します。 プッシュメッセージ購読資源とプッシュ資源が作成されます。 プッシュメッセージ購読集合を必要なら作成し (要求で指定されていればそれを選択し) て、 作成したプッシュメッセージ購読を追加します。

[19] プッシュサービス資源は、 要求で指定されたプッシュメッセージ購読集合が非妥当なら、 400 応答を返さなければなりません。 >>1 4.1. 異なる利用者エージェント用のプッシュメッセージ購読集合が指定されるのは不適当でしょうし、 プッシュメッセージ購読集合でないものが指定された場合もそうでしょう。

[20] プッシュサービス資源は、 プッシュメッセージ購読集合の指定のない要求を、 429 応答で拒絶して構いません。 >>1 4.1. 同じ利用者エージェントがいくつもプッシュメッセージ購読を作成し、 プッシュメッセージ購読集合にまとめられないのは不適当で不審な挙動と考えられます。

[69] 同じ利用者エージェントであるかどうかの判断方法は、 実装依存です。 >>1 4.1. 現在の Webブラウザーの配布形態は、 特別な利用者登録なしに自由に実行できるものとなっていますから、 事前交換情報に基づく認証による確実な識別ができません。 IPアドレスその他から推測することになりますが、 どの方法であれ確実とはいえません。 おそらく、 Webブラウザー依存の方法で利用者エージェントを識別する何らかの情報を Webブラウザー側で保持しておき、 これを毎回要求に追加して同一性判定に供することになるのでしょう。 プッシュサービスは任意の方法で認証できます >>1 8.3.。

[66] application/webpush-options+json 以外の要求本体は、 無視しなければなりません。 >>27

[67] application/webpush-options+json 要求本体のうち、 理解できない JSONオブジェクトのメンバーは無視しなければなりません。 >>27

[68] 要求本体がJSONオブジェクトでないときどうするべきか不明です。

[64] プッシュサービスは、 公開鍵を必須にできます。 subscribe

[14] 作成に成功したら、応答を返します。

[63] 本体については何ら規定がありません。 すべての情報は HTTPヘッダーで記述されるので、 省略し無視するのが適当と思われます。

[62] プッシュサービスは、負荷対策のため他のサーバーに分散させられます。 利用者エージェントは、 307 応答に対応しなければなりません。 >>1 7.1. 明記されていませんが、 Location: でリダイレクトされた URL に POST し直すことが期待されていると思われます。 同じ起源とは限らない (違うサーバーなので違う可能性も高い) と思われますが、 任意の外部サーバーへのリダイレクトを認めてよいのか、 利用者エージェントの設計上注意が必要かもしれません。

[65] その他、 明文規定はありませんが、当然、利用者エージェントはエラー処理が必要です。

実装

[74] Chrome は違う applicationServerKey で既に subscribe 済みなら拒絶します・

[72] Chrome は userVisibleOnly が偽なら拒絶します。

[55] Chrome でなぜか subscribe メソッドの Promise が解決されなくなることがあります。 なぜか全然応答しなくなり、固まっているようにみえます。 通知の許可を変更したり、リセットしたりしても解決しません。 Chrome を再起動するとあっさり治ります。

メモ