On 8 July 2014 14:25, Martin Thomson <> wrote:

> 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.

but I have pointed out in the past that the encoder header size is a
reasonable indication of additional memory requirements represented by the
header block.   The highly compressed fields within a header block are the
indexed ones, and they reference memory in the header set that is already
constrained by a setting.

The setting at least tells a receiver what memory commitment is required to
analyse the header to discover it's true size.   It may be that some
implementation may accept a header based on the limit applied to the
encoded size, but then still decide to 431 it because of the expanded size.


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Tuesday, 8 July 2014 05:36:35 UTC