仕様書

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

[14] アプリケーションサーバーは、 プッシュメッセージをプッシュ資源に送信し、 配送を要求します。 >>2 5. アプリケーションサーバーは事前にプッシュ購読のプッシュエンドポイント (プッシュ資源の URL) や、その他必要な情報を知っておく必要があります。 プッシュ購読

[15] アプリケーションサーバーは、 プッシュ購読プッシュ購読、 データ、 TTL秒数 TTL、 Urgency: の値または null urgency Urgency: 、 Topic: の値または null topic Topic: 、 配送確認の希望の有無配送確認について、 次のようにします。

[23] 以前に要求のURLの起源と同じ起源に配送確認を要求して受領証購読資源の URL を受け取っていた場合、 要求に 受領証購読資源の URL を urn:ietf:params:push:receipt として関係URLを設定するべきです。 >>2 5.1.

[25] ただし、 当該受領証購読の寿命の間、 受領証を集約して受信することができないなら、 受領証購読を省略して構いません。 アプリケーションサーバーが他のプッシュメッセージ送信者のかわりに受領証購読を監視するような場合に、 その必要があるかもしれません。 >>2 5.1.

[54] プッシュサービスは、 プッシュメッセージ購読が満期の場合、 404 応答を返さなければなりません >>2 7.3.。

[60] プッシュサービスは、任意の方法で認証できます。 >>2 8.3.

[61] プッシュサービスは、 DoS攻撃対策として、 プッシュメッセージを特定利用者エージェントに配送する速度を制限するべきです。 制限を超えた時プッシュサービスは 429 応答を返すことができます。 Retry-After: ヘッダーに待機時間を指定するべきです。 過大なプッシュメッセージを受け取ったプッシュメッセージ購読を終端させても構いません。 >>2 8.4.

[62] プッシュメッセージ購読が特定アプリケーションサーバーに制限されている場合 (プッシュサービス資源を使って作成したときに公開鍵が指定された場合)、 要求について VAPID の処理をしなければなりません。 VAPID

[72] プッシュサービスは、 VAPID の JWT や公開鍵を利用者エージェントに転送してはなりません。 >>63

[51] プッシュサービスは、 実体本体が大きすぎる場合、 413 応答を返して構いません。 4096 バイト以下なら、 413 を返してはなりません。 >>2 7.2.

[29] TTL: ヘッダー、 Urgency: ヘッダー、 Topic: ヘッダーを処理しなければなりません。 Topic: ヘッダーの指定に基づき、 既存のプッシュメッセージが削除されることもあります。

[19] プッシュサービスは、 プッシュメッセージを受け取ったらプッシュメッセージ資源を作成します。

[19] プッシュメッセージ資源の URL は、 プライバシーのため、 プッシュメッセージ購読間の関係性を含むものであってはなりません。 関連付けられたプッシュメッセージ購読との関係や、 同じプッシュメッセージ購読の他のプッシュメッセージとの関係を示すものであるのは構いません。 利用者や装置の情報を含めてはなりません。 同じプッシュメッセージ購読に関連付けられたプッシュメッセージ資源の URL から利用者エージェントとの関係を知れるものであってはなりません。 >>2 8.2.

[24] 配送確認 (Prefer: respond-async) が求められた場合、 受領証購読資源を必要なら作成します。 要求で指定されている場合は、 可能ならそれを再利用するべきですが、 無理なら新しいものを作っても構いません >>2 5.1.。 実装依存の制約 (有効期限など) で再利用できないこともありましょう。

[26] 要求で指定された受領証購読が非妥当なら、 400 応答を返さなければなりません。 >>2 5.1. 異なるアプリケーションサーバー用の受領証購読資源が指定されるのは不適当でしょうし、 受領証購読資源でないものが指定された場合もそうでしょう。

[27] 受領証購読数を制限したい場合、 受領証購読の指定のない要求を、 429 応答で拒絶して構いません。 >>2 5.1.

[50] 配送のため蓄積するプッシュメッセージには、 アプリケーションサーバーが配送を求めた時刻を表す Last-Modified: ヘッダーを含めるべきです。 >>2 7.2. これは要求を受理した時点での現在時刻を保存し、 TTL: の計算に供するべきとの趣旨と思われます。 後にプッシュメッセージを配送するときにこの時刻を利用者エージェントに送付するべきなのかどうかは、 何とも書かれていません。 (利用者エージェントは特にこれを使わないので、送付するべきではないとみられます。) アプリケーションサーバーが既に指定していた場合にどうするかも規定されていませんが、 TTL: の計算に用いる趣旨ならば、これは無視する (削除する) べきでしょう。

[17] プッシュメッセージを受理した場合、 201 応答を返します。 まだこれは利用者エージェントにプッシュメッセージが配送されたことを意味しません。 >>2 5.

[21] プッシュメッセージを受理した場合で、 配送確認 (Prefer: respond-async) が求められた場合、 202 応答を返さなければなりません >>2 5.1.。

[18] Location: ヘッダーに、 作成したプッシュメッセージ資源の URL を記述しなければなりません。 >>2 5., 5.1.

[22] 配送確認が求められた場合、 リンク関係型 urn:ietf:params:push:receipt で受領証購読資源の URL を記述しなければなりません。 >>2 5.1. Link: ヘッダーを使えます。

プッシュサービスから

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

実装

[17] Firefox は https://updates.push.services.mozilla.com/push/v1/... のようなエンドポイントURL を使っています。 メッセージを渡さないなら、何でも良いので POST だけすればOKです。 各エンドポイントURLにそれぞれ POST する必要があります。

[45] Firefox は applicationServerKey なしで subscribe できます。 https://updates.push.services.mozilla.com/wpush/v1/... のような URL を使っています。 ただの POST では受け付けてくれません。 TTL: ヘッダーがあれば他はなにもない POST でも受け付けてくれます。 2019-01-03T12:14:20.800Z

[51] Chrome は applicationServerKey なしで subscribe できず、 拒絶されます。 ありだと https://fcm.googleapis.com/fcm/send/... のような URL を返してきます。 ただの POST では受け付けてくれません。 Authorization: ヘッダーがないと 400 UnauthorizedRegistration を返します。 Authorization: ヘッダーが構文エラーだと 500 Internal Server Error を返します。 Authorization: ヘッダーの内容がおかしいと 400 InvalidParameters を返します。 Authorization: ヘッダーの k= が違う鍵だと 403 MismatchSenderId を返します。 暗号化された本体データが壊れていても、 201 Created を返して成功に見えますが、 Webブラウザーには (あるいはサービスワーカーには?) 伝わりません。 本体がまったく含まれておらず Content-Encoding: もなければ正常に処理されます。 TTL: がないと 400 InvalidTtlParameter を返します。 sub は省略可能です。 unsubscribe 済みだと 410 NotRegistered を返します。 2019-01-04T01:08:53.900Z

メモ