search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
146 stars 40 forks source link

The user agent should be permitted to acknowledge even if the SW rejects #196

Closed martinthomson closed 8 years ago

martinthomson commented 8 years ago

This prevents a poisonous push message from being retried indefinitely. Well, by the push service at least.

I've included a note about soft update, which I think offers the SW a hope of correcting a problem. If it were up to me, I would soft update after the first failure, soft update with the force bypass cache flag set after the second failure, and acknowledge on the third.

mvano commented 8 years ago

It seems like some relevant information is not passed to the server this way. The message got to the user agent, but failed to be correctly delivered to the web app. Acknowledging covers the former, but not the latter. Is there a way to cover both?

brianraymor commented 8 years ago

Elio Damaggio made a related proposal in the WebPush WG to allow user agents to return opaque diagnostic data to their application servers in an optional Acknowledgement-Data header forwarded by the push service with an acknowledgement. We closed the issue until we had more clarity if there was demand for such a feature.

Something along the lines of:

If a push message has a Push-Receipt header field, the user agent MAY include exactly one “Acknowledgement-Data” header field in its acknowledgement request. The content of the Acknowledgement-Data header field is opaque diagnostic data encoded as a base64url string. The ABNF [RFC5234] production for "token68" is defined in Section 2.1 of [RFC7235].

If the application has requested a delivery receipt, the push server MUST include the Acknowledgement-Data header field with the response to the application server monitoring the receipt subscription resource.

mvano commented 8 years ago

I'm ok with waiting for demand of something like Acknowledgement-Data before adding it. This change is fine to merge then. Thanks!