Declarative Web Push: `pushSubscriptionChange` requires Service Worker

[Dygear]

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

[saschanaz]

Good catch, perhaps the subscribe() can have an extra URL field, then no well-known will be required.

[Dygear]

Good catch, perhaps the subscribe() can have an extra URL field, then no well-known will be required.

I'd be happy with that as a solution as well.