Re: [w3c/push-api] Retry push event (#300)

I am talking about point 2. The *application server* can be temporary inaccessible due to maintenance or due to internet connection problems that are not caused by the *application server* itself - e.g. the user device looses the internet connection after receiving the `push` signal but before or during the `fetch`.

> the application server might send another push message if it doesn't get contacted in a reasonable amount of time

In that case **the *application server* has received a `200` status code from the browser *push service* and *must* be contacted by the UA**.
The application server doesn't know if the `push` signal is lost  or the device is simply turned off for example. So what is a reasonable amount of time? I think that your solution would greatly increase the workload / complexity for the application server; the application server would also flood the browser push service with useless / redundant `push` signals; the application servers that don't make retries (*)  will sometimes loose notifications

(*) Actually it makes sense to not perform retries: you have received a `200` response. I am pretty sure that most applications will implement web push without the (complex) kind of retries that you are describing, thus getting an unreliable service.

IMHO The Push API / service workers should provide a way to process the event in a reliable way.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/300#issuecomment-418080578