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

Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues)

From: Michael Sweet <msweet@apple.com>
Date: Fri, 18 Jul 2014 15:10:18 -0400
Cc: Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <9DC51AAF-6B3D-4DA8-9FC8-793137BBC75C@apple.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Jul 18, 2014, at 2:24 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 18 July 2014 10:57, Jason Greene <jason.greene@redhat.com> wrote:
>> Itís extra complexity, but the implementation isnít difficult (a cake walk compared to other aspects of the spec). I can certainly appreciate the perspective from implementations that donít want to touch their code though.
> I realize that this is a standard sophist technique in this forum, but
> I find that selectively trivializing various aspects of the space
> isn't particularly constructive.  Let's try to be even-handed in our
> analysis.
> On the one side:
> CONTINUATION has a cost in code complexity.  It defers the discovery
> of what might be a surprisingly large amount of state.
> On the other:
> A hard cap on size (i.e., option A) has a cost in code complexity.  It
> requires that encoders be prepared to double their state commitment so
> that they can roll back their header table when the cap is hit.  When
> you consider compression, it does not prevent there from being a
> surprisingly large quantity of header information.

Actually, there is a simple solution to this problem - add a flag causes the header table to be reset/cleared before the frame is processed.  The sender can set the flag when it has tried preparing a HEADERS frame and made one too big, or when it gets a 431 response that indicates the recipient was unable to process it fully.

That solves the header-table-is-out-of-sync and allows the sender to maintain a single header table should that become too much of a burden (although constrained endpoints can always specify settings to disable the header table on their end and always use encoding that doesn't add values to the header table...)

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 18 July 2014 19:10:48 UTC

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