Declarative Web Push: `pushSubscriptionChange` requires Service Worker

Aperta
  • Qualcosa non va?
#401 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
html
Ambito
api

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
HTML
Stelle
158
Fork
43
Merge medio
2g 6h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di w3c/push-api

Tutte le issue di w3c/push-api

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.