On 7 July 2014 21:07, Mark Nottingham <> wrote:
>> 1) declaring a limit on the compressed header size
>> #1: Sure, though I suspect its utility will be minimal when proxies/gateways are in the mix.
> This would partially mitigate #550, and substantially help #551.

I haven't repeated myself here, because I don't like doing that, but I
have pointed out in the past the poor correlation between compressed
frame size and the actual state commitment required.

The conclusion I'd drawn there being that a limit on encoded header
block size doesn't really do anything to limit the state commitment
required to process a request or response.  There is definitely some
utility in having a limit, but it's marginal.

The setting really only becomes useful - and arguably necessary - when
you consider the expanded frame size.

>From that perspective, I'd rather consider the setting in combination
with the expanded frame size.  If we were to consider the addition of
just the setting, I think that I'd be sad that you had made the
protocol have more moving parts for no real gain.

Received on Tuesday, 8 July 2014 04:26:21 UTC