W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #541: CONTINUATION

From: Greg Wilkins <gregw@intalio.com>
Date: Tue, 8 Jul 2014 15:36:06 +1000
Message-ID: <CAH_y2NG5E0ppcPwKOmut2wKcQwsk1VwBvVeabDNkd4NHXD+W+g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Jason Greene <jason.greene@redhat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC