Re: [Webpush] Require the TTL header

[Benjamin Bangert <[e-mail]>]

On Fri, Feb 5, 2016 at 8:29 AM, Brian Raymor <[e-mail]>
wrote:

>
>
> If you don’t create a push message resource, how do you handle all the
> related dependencies?
>
>
>
> For example, Receiving Push Messages:
>
>
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7
>
>
>
>    Each push message is pushed as the response to a synthesized GET
>
>    request in a PUSH_PROMISE.  This GET request is made to the push
>
>    message resource that was created by the push service when the
>
>    application server requested message delivery.
>

In our system we determine if the user agent is available as we process the
notification from the application server and attempt delivery immediately
if so.


>  and in Acknowledging Push Messages:
>
>
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.2
>
>
>
>    To ensure that a push message is properly delivered to the user agent
>
>    at least once, the user agent MUST acknowledge receipt of the message
>
>    by performing a HTTP DELETE on the push message resource.
>
>
>
> There is also a caveat in the TTL section that the push message resource
> may be deleted before the acknowledgement:
>
>
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-6.2
>
>
>
>    A Push message with a zero TTL is immediately delivered
>
>    if the user agent is available to receive the message.  After
>
>    delivery, the push service is permitted to immediately remove a push
>
>    message with a zero TTL.  This might occur before the user agent
>
>    acknowledges receipt of the message by performing a HTTP DELETE on
>
>    the push message resource.  Consequently, an application server
>
>    cannot rely on receiving acknowledgement receipts for zero TTL push
>
>    messages.
>

 It looks like our current choice of not returning a Location if the user
is offline is not to spec, since returning a 201 implies it must contain a
Location header. We will be changing this to a 400 for a Bad Request if the
TTL header is missing in the future, and always include the Location field
for TTL: 0 messages.

Cheers,
Ben