Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements

So, nacking in the case that we have to clear a client's notifications (too
many) feels like it can cause a really nasty infinite loop error.

Here's the situation I'm seeing:
1. User hits limit on the most queued messages the Push Service wishes to
hold at once for a single client.
2. On the next incoming notification, Push Service clears out the client's
notification queue to make space for new notifications. (I believe GCM
already will drop a bunch of notifications at once when this happens)
3. We send out NACK's for all the dropped notifications
4. App-Servers get nack's and decide to resend notifications.
5. Go to step 1.

What steps are being taken with NACK's to ensure an app-server doesn't do
something like this? Is there going to be some status code or something to
indicate that these messages shouldn't be retried for some period of time?

Or is it going to be up to a Push Service to try and detect these loops,
and when they occur, the Push Service is just going to have to fully expire
all the clients subscriptions to stop the loop?

On Wed, Oct 14, 2015 at 3:02 PM, jr conlin <jconlin@mozilla.com> wrote:

> On 10/14/2015 2:37 PM, Martin Thomson wrote:
> > On 14 October 2015 at 14:09, JR Conlin <jconlin@mozilla.com> wrote:
> >> 429: This will allow the server to apply "back pressure" to the
> >> application service in cases where there may be too many incoming
> >> messages in a short period of time. This response would carry a
> >> RETRY-AFTER response header indicating the number of seconds that should
> >> elapse before the remote server should retry transmission of the
> message.
> >
> > How is that different from 503?
>
> Traditionally (as if that's a thing for the web) 503 tends to be used by
> intermediary services like load balancers to indicate that "something's
> amiss with the box I normally talk to". Since it's a 500 class error, it
> indicates an error state possibly from outside the server. 429 was
> identified as part of https://tools.ietf.org/html/rfc6585 to be used
> more as a rate limiter and carries with it the "Retry-After" response
> header indicating how long the requester should wait before retry. It's
> a 400 class error, which means it should come from the responding server.
>
> Either would work, of course, but it may be that programmers can take
> advantage of pre-existing handlers in libraries to do the back-off for
> them, rather than have to code the response themselves.
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>