Declarative Web Push: `pushSubscriptionChange` requires Service Worker

Abierto
  • ¿Algo no está bien?
#401 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
html
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
HTML
Estrellas
158
Forks
43
Merge medio
2 d 6 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de w3c/push-api

Todos los issues de w3c/push-api

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.