Declarative Web Push: `pushSubscriptionChange` requires Service Worker

オープン
  • 何か問題がありますか？
#401 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
html
領域
api

調査の方向性

Read the Declarative Web Push proposal in the issue and compare its suggested POST payload and /.well-known/pushsubscriptionchange endpoint with the existing Push API specification. Work out how subscription changes should be delivered without a service worker and what the specification must define; done means the issue's gap has a resolved design and corresponding specification changes.

索引モデルが issue の本文から書いたものです。

説明

The promise of Declarative Web Push is that it doesn't require a service worker in order to function. There is however one area that is not covered and that is the pushSubscriptionChange event that is handed to the service worker when a user-agent changes its endpoint, p256dh, and auth values. This is often handled like so ...

self.addEventListener('pushsubscriptionchange', function(event) {
  event.waitUntil(
    fetch('https://update.url/path', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        old_endpoint: event.oldSubscription ? event.oldSubscription.endpoint : null,
        new_endpoint: event.newSubscription ? event.newSubscription.endpoint : null,
        new_p256dh: event.newSubscription ? event.newSubscription.toJSON().keys.p256dh : null,
        new_auth: event.newSubscription ? event.newSubscription.toJSON().keys.auth : null
      })
    })
  );
});

The updated information needs to get to the server that is responsible for generating the WebPush payloads. They need to have current, correct information in order for the payloads to get to their intended target. When a user-agent decides that it wishes to update its endpoint, p256dh, and auth values the pushSubscriptionChange event is fired with the old and new values. Not having this information produces a dangling reference in the servers database until finally it attempts to send a Push to the user-agent's endpoint and receives a 410 Gone reply.

That is a gap in the current Declarative Web Push implementation.

I come to you not just with the problem, but perhaps a potential solution. Given that the goal is to not have a service worker, we could use the /.well-known/ directory structure to inform the server of a pushSubscriptionChange. I propose that the user-agent would send its subscription changes to /.well-known/pushsubscriptionchange URL of the domain that the push notification is subscribed from. That payload would be a POST request with the payload of Content-Type application/json having the payload like the current pushSubscriptionChange payload.

{
  "oldSubscription": {
    "endpoint": "CURRENT_URL"
  },
  "newSubscription": {
    "endpoint": "NEW_URL",
    "keys": {
      "p256dh": "NEW_P256DH",
      "auth": "NEW_AUTH"
    }
  }
}

Also Tracked Here:
WebKit BugZilla #294421

主要言語
HTML
スター
158
フォーク
43
平均マージ
2日 6時間
マージ済み PR（30日）
2

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

w3c/push-api のほかの issue

w3c/push-api の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。