- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 7 Jul 2014 21:25:54 -0700
- 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