RE: Flow control for server push

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: mardi 3 mai 2016 07:35
> To: Roy T. Fielding <fielding@gbiv.com>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: Flow control for server push
> 
> On 3 May 2016 at 05:06, Roy T. Fielding <fielding@gbiv.com> wrote:
> > Are we concerned about a server accidentally sending too many pushes,
> > or deliberately attacking the client via too many pushes?
> 
> It's the former, accidental overloading.  And it's not really an attack, just an
> infidelity.  We did a lot to provide feedback mechanisms where there was a
> risk of overload, and we missed this tiny corner case.
> 
> As with the push policy stuff, the point is to avoid having a server send
> pushes when the client doesn't really want them.
> 
> > Not (2) -- that's overkill.  (1) seems a shame given that it won't
> > prevent a server from sending pushes, and doesn't feel right given
> > that a client has no idea how many pushes it might need.
> 
> I agree on both counts.  I haven't been able to contrive anything that works
> without ugly side-effects of one sort or other.  I'll probably write a draft with
> a few ideas in it and see what people think when confronted with specifics.

I think that limiting the number of pushes fits well in the push-policy draft [1] as a new push-policy.
Using something like a push-policy has the advantage of covering the WebPush use case, Stuart's use case of pushing nothing for a specific request, and to be extensible to future use cases.
The main drawback is that push is hop-by-hop and that the headers may survive for more than one hop.

I can update the draft when I have some available time.

Hervé


[1] https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-01

Received on Wednesday, 4 May 2016 10:25:15 UTC