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

[Idel Pivnitskiy <[e-mail]>]

Agree with Benjamin,

In current spec if decryption or decoding fails, ack will not be
sent. Consequently, PS will try to resend a message after some delay
without ack and situation will repeat again. Lucky if it will not lead the
crash of an application again and again.

Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

On Wed, Jun 8, 2016 at 4:42 PM, Benjamin Bangert <[e-mail]>
wrote:

> I'm in support of at-least-once processing, so the ack would occur last per
> the DOM API. The difference would be that the DOM spec should require
> ack even if decryption fails or the SW fails for some reason.
>
> On Wed, Jun 8, 2016 at 12:38 AM, Martin Thomson
> <[e-mail]> wrote:
> > I'm sorry, I'm confused by your message.  I can't decide if you want
> > at-least-once, or at-most-once.  End-to-end ack, i.e., ack after
> > successful processing, is in support of at-least-once, which I think
> > is consistent with other decisions we've made in the overall design.
> >
> > On 8 June 2016 at 15:15, Benjamin Bangert <[e-mail]> wrote:
> >> 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.)
>