On 8 July 2014 14:25, Martin Thomson <martin.thomson@gmail.com> 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. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Tuesday, 8 July 2014 05:36:35 UTC