Re: [Webpush] Require the TTL header

[Costin Manolache <[e-mail]>]

+1 on requiring ttl, and returning a Location even for TTL=0

However receipt behavior is a bit tricky. The service may 'delete
immediately' ( which is the same with
not storing it in the first place ), but the delivery receipts should still
be returned when the device
acks.

The push service may believe the device is connected, and call send - but
in many cases send
will succeed even if the other end is gone - TCP will do its retry and
eventually will timeout and
close the connection, but it takes some time and it's well after send.

I assume 202 (Accepted) would be better for TTL=0 if the service is not
actually storing the message.

GCM ( and I assume other services ) may also optimize small TTLs by not
persisting - so
it may make sense to indicate this with 202, and not require in the spec
that the service is persisting
all messages.

Finally, it is very impractical for us to determine if the user agent is
available at the time of the send
(replication and cross-DC latency, plus the TCP retries)

Costin



On Fri, Feb 5, 2016 at 9:09 AM, Benjamin Bangert <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>
>