Re: Flow control for server push

> Am 02.05.2016 um 08:39 schrieb Martin Thomson <>:
> On 2 May 2016 at 12:26, Martin Thomson <> wrote:
>> 1. A header field that limits the number of pushes in response to any
>> given request, maybe something that builds on Herve's push policy
>> work.
> I just realized that a header field might be problematic in that
> server push is a hop-by-hop mechanism and header fields would pass
> intermediaries.

The undiscovered country of server pushes. It will take some time to map that out.

> The problem with anything that isn't coupled to the request is that it
> becomes quite imprecise.  Any request that the client makes either
> counts toward a global limit, or adds an opportunity for the server to
> push another tranche of messages.

And the order in which requests are processed is totally up to the server (guided by priority) and may encounter delays the client is unaware of.

The global limit seems to say: "I can only handle X at a time, do not send me more".
The request specific limit: "I do not want/want at most X sub-resources for this one."

I'd assume - browser devs might want to correct me on this - that for the majority of requests a client will have no real use for sub resources. While having the cache populated is nice, it is *this* request it wants to process as fast as possible.

That would be an argument for something that defaults to "no push", without intermediaries/servers having extra processing for the common case. Something like a new SETTING that says: the NOPUSH I sent you, please ignore that for streams that carry XXX. And XXX could be a header like Push-Policy.


Received on Monday, 2 May 2016 08:21:00 UTC