Re: [Webpush] Use Case related to subscription sets

[Benjamin Bangert <[e-mail]>]

On Fri, Nov 20, 2015 at 2:40 AM, Hervé Ruellan <[e-mail]>
wrote:

>
>
> On 18/11/15 19:20, Benjamin Bangert wrote:
>
>> I'm not sure any changes would be needed as is. If a Push Server is
>> limiting the concurrent streams, the proxy could just open several
>> connections, one for each device its proxying for that devices
>> subscription set.
>>
>
> The main concern for us is a Push Server enforcing only one subscription
> set for a client: in our use case, this client would be the proxy (from the
> WebPush point of view). However, we could have several devices "hidden"
> behind this proxy, and we want to keep them independent.
>

If a Push Server chooses to constrain concurrent streams, that's entirely
within its right to do so. One solution for this use-case may be to have
the proxy register the subscription sets for each of the devices using it,
then switch to a polling model, polling each registered subscription set in
turn periodically, though that could bump into request limiting.

If a proxy is going to put additional load on a Push Server, then the
people running the proxy should run the Push Server as well so that they
can shoulder the burden of their use.

Since most push servers, as far as I know, will be using SSL, I don't know
how a proxy could even function since it would need to MITM the secured
connection which is obviously not good.

Either way, this situation and use-case seems accounted for by the spec as
it is, since those wishing to handle this scenario may run their own Push
Server without a low concurrent stream max, and unsecured so that a proxy
may function.

Cheers,
Ben