Re: [Webpush] Require the TTL header

[Costin Manolache <[e-mail]>]

On Sat, Feb 6, 2016 at 1:40 PM, Benjamin Bangert <[e-mail]>
wrote:

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

What I meant is: if TTL=0, don't store the message, and return 202
(Accepted) regardless of user status, since
no resource is actually created. However in order to return a delivery
receipt, it needs to have an identifier.

Regarding privacy implication - the delivery receipt has the same
characteristics, if you send a message and later
get a delivery receipt, it implies the user recently connected, and you can
estimate how long he was offline.
It's not very precise - at least GCM batches and may delay receipts, I
don't think the draft requires immediate
delivery of a receipt.

In either case - a very useful feature would be to reject a message if user
has not been connected for a 'long' time -
I think this is covered implicitly by the expiration of the subscription.



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

I suspect nobody will, one of the benefits of TTL=0 is that it's likely to
be cheaper and faster in most
implementations.

Costin


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