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

Re: #541: CONTINUATION

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 7 Jul 2014 21:25:54 -0700
Message-ID: <CABkgnnVevm3ar2EG_S8iQ-7sXEPcsTFYAao=GP=D83zS=NEttw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: 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 7 July 2014 21:07, Mark Nottingham <mnot@mnot.net> 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

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