Re: [Webpush] When UA should send an acknowledgement?

[Benjamin Bangert <[e-mail]>]

On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson <[e-mail]> wrote:
> On 8 June 2016 at 13:17, Benjamin Bangert <[e-mail]> wrote:
>> For our implementation, we will actually never send more notifications
>> until all sent ones are ack'd. This means if a message is malformed or
>> causes a UA error in a UA that actually follows the DOM spec, it will
>> never get a notification again (except the notification it won't ack).
>
>
> This is fine, as long as you regard unacknowledged messages that you
> thought were delivered as poisonous after a certain amount of time (or
> retries, if you do that).  If you follow that advice, then progress
> will eventually be made.

This recommendation isn't in the WebPush spec. By mandating that the UA
MUST ack every message it's clear that failure to ack a message should
result in redelivery attempts.

If it's intended that a UA does not need to ack every message, the WebPush
spec should be updated to reflect that. I could see a PS reasonably
considering messages dead if other messages were ack'd or some other
command came over the connection such that the server knew that
the client is alive and likely processed it.

Automatically ack'ing a message in this manner for the PS has as many
problems if not more than requiring the UA to ack every message though.
It also introduces a lot of complexity into the PS and may result in very
long message delivery times should a UA get bogged down with many
improperly encrypted messages.

>
> I expect that Costin will agree with you, but we've discussed this in
> the past.  The problem here is that an acknowledgment from the user
> agent doesn't constitute a useful signal.  You have moved the problem
> to a second middle-man.  When the user agent acknowledges prior to
> processing the message, how will the application know that it was
> processed?  Can you guarantee that?  When the browser crashes, your
> message is still lost.

Why not change the DOM spec to indicate that if a message was
processed and failed for some reason it should still be ack'd?

If the same message consistently crashes the browser, I would expect
the browser to track that fact and avoid the message again in the future.

Clearly we have the choice of guaranteeing that a message will be
processed at-most-once, or at-least-once, since a crash immediately
after processing could stop the ack from making it back. If the desire
is at-most-once, then the UA should ack immediately upon receipt of
the message (or the PS can consider it ack'd if a PING frame is
returned after sending a message, etc.).

The Push DOM spec seems to favor the at-least-once model, in which
case it would be appropriate for the UA to always ack a message even
if it decrypts improperly, or the SW throws an exception, etc.

>
> The only way for this to be a good signal is to have the
> acknowledgment be end-to-end.
>
> (p.s., I don't know if your assertion is true or not.  I don't think
> that it matters.  I should know that code, but it's an absolute rats
> nest, despite Kit's recent efforts at cleanup.)