Re: [Webpush] Receipt subscription follow-up

[Costin Manolache <[e-mail]>]

The main purpose of the DELETE ( from my perspective ) is to prevent
PS flooding the AS, i.e. to provide a form of flow control. Secondary
reason is to provide more info for load balancing the receipts across
AS connections.

Having retry on the receipt would be expensive - I think it would
be better to not promise that, not sure about other PS but for us it
may be tricky. Retry if a AS connection goes down, or it doesn't ack
is ok - but not for the entire duration of the message TTL,
and without reliability guarantees, i.e. without database storage.

Costin



On Wed, Apr 27, 2016 at 10:22 AM Brian Raymor <[e-mail]>
wrote:

>
> On Tue, Apr 26, 2016 at 9:21 PM Martin Thomson <[e-mail]>
> wrote:
> ...
> > However, in this case, can we request that the application server
> > DELETE (just like the client uses DELETE to acknowledge)?
>
> To clarify, you're proposing that the application server delete the same
> push message resource that was deleted by the user agent to acknowledge
> receipt of the message? If so, something like:
>
> If the push service receives the acknowledgement and the application
> has requested a delivery receipt, the push service MUST return a 204
> (No Content) response to the application server monitoring the
> receipt subscription.
>
> To ensure that a receipt is properly delivered to the application
> server at least once, the application server MUST acknowledge receipt
> of the response by performing a HTTP DELETE on the corresponding
> push message resource.
>
> If the push service does not receive the acknowledgement within a
> reasonable amount of time, then the receipt is considered to be not
> yet delivered. The push service SHOULD continue to retry delivery of
> the receipt until the advertised expiration of the corresponding push
> message.
>
>
>
>
>
>
>