Bug 294421 – Declarative Web Push: pushSubscriptionChange requires Service Worker

• Status: NEW
• Component: New Bugs

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`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/pushsubscriptionchange_event) 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 ...

```js
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/`](https://datatracker.ietf.org/doc/html/rfc8615) 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.

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

Also Tracked Here:
GitHub: [W3C Push-API Issue #401](https://github.com/w3c/push-api/issues/401)

[Radar WebKit Bug Importer]

<rdar://problem/153857526>

It has been suggested on GitHub by saschanaz that Push Manger subscribe function could also have an extra argument or the passed options includes a value for a pushSubscriptionChange URL. I'd be happy with any of the above options.

https://developer.mozilla.org/en-US/docs/Web/API/PushManager/subscribe

[Ben Nham]

We don't currently emit the pushsubscriptionchange event for any type of Web Push in WebKit. The last I checked (which admittedly was years ago), none of the browsers were emitting this event. For the most part, it's not necessary because the subscriptions we create don't have an expiration date on them.

If we end up creating expiring subscriptions, then we'll start emitting the pushsubscriptionchange event and we'll probably have to think about how to handle the event if you don't have a service worker.