Re: Flow control for server push

Hi Willy,

On 2 May 2016 at 15:20, Willy Tarreau <w@1wt.eu> wrote:
> In fact SETTINGS_ENABLE_PUSH could have been a
> limit instead of a bit, since not supporting push is equivalent to setting
> its limit to zero.

That opportunity passed already, so we'd be making a new setting.

> However if the purpose is to limit network usage or protocol processing
> work, then I think that we could communicate a limit on the number of
> response headers.

The question I have is whether this is a good proxy for the thing
we're concerned about.  That's the problem I have with any option that
attempts to establish a budget.  Are we budgeting for the right thing?

I agree that we could rathole indefinitely on the question of bytes
(pre-encoding, post-encoding?) vs messages. But is the additional
granularity of header field count adding value?

(I'm purposefully ignoring secondary benefits of your proposal here: I
really wish that servers would have some incentive to stop sending me
useless headers, e.g., see slide 15 of [1].)

My experience suggests that the incremental effort of processing an
extra header field is negligible, since most header fields are
basically ignored. Whereas the push itself implies a direct and
tangible cost.


[1] https://github.com/httpwg/wg-materials/raw/gh-pages/ietf95/BC.pdf

Received on Monday, 2 May 2016 05:36:41 UTC