Re: [Webpush] Require the TTL header

[Benjamin Bangert <[e-mail]>]

On Sat, Feb 6, 2016 at 12:47 PM, Costin Manolache <[e-mail]> wrote:

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

I realized on more careful reading that to return a 201, a Location must
accompany it, so our implementation was wrong in this regard.

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.
>

I'd be in favor of that, not sure if there's any relevant privacy
implications from immediately indicating that a user is offline. And as you
note, it still leaves open the possibility of returning a 201 with the
belief the client is connected before it times out on the TCP retries. So
all the 202 indicates in this regard is that the client is definitely not
connected, nor has been recently enough for a stale connection to be
present.


> 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.
>

Yep, we don't store TTL=0 messages at all.


> 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
>

Cheers,
Ben