Re: [Webpush] Receipt subscription follow-up

[Costin Manolache <[e-mail]>]

Reading more closely - I think it is fine, the PS is free to return a
different receipt URI, regardless
of what is included.
So a PS requiring VAPID can just return the same URL, based on VAPID.

Costin

On Mon, Apr 25, 2016 at 10:18 PM Costin Manolache <[e-mail]> wrote:

> You mean an AS having multiple instances would use a different
> receipt set for each instance ? That may be problematic for many
> reasons - like load balancing, queuing, AS server restarts.
>
> I would expect most PS will want to be able to load balance across
> multiple connections from AS, and deliver receipts locally, i.e. if a
> device is in EU to use AS connections in EU (if the AS has connections
>  in different regions). And if an AS instance restarts, receipts would
> go to the remaining.
>
> Costin
>
>
>
> On Mon, Apr 25, 2016 at 10:03 PM Martin Thomson <[e-mail]>
> wrote:
>
>> On 26 April 2016 at 14:47, Costin Manolache <[e-mail]> wrote:
>> > Seems reasonable - but it should be optional if an App Server is using
>> > VAPID,
>> > since the push service can simply use the VAPID public key, and it
>> > simplifies the
>> > AS logic.
>>
>> I was talking primarily about what the application server has to do to
>> decide what to send.
>>
>> If this were solely rate limiting, I'd agree.  The choice to send 429
>> can definitely use the token.  The problem is if there are multiple
>> application server instances and the push service decides to send the
>> same subscription back to two different instances, then things might
>> break.  The inclusion of the receipt subscription in the request is
>> permission to merge receipts.  The push service shouldn't merge
>> receipt subscriptions without permission.
>>
>