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:28:39 -0400
Cc: Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <13AFF663-F9CF-4CC8-AC6F-DC43E4485CEC@apple.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Jul 18, 2014, at 3:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 18 July 2014 12:10, Michael Sweet <msweet@apple.com> wrote:
>> 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...)
> We do already have that capability.

I know we have a setting for the max header table size, and the recipient can clear the sender's header table by setting the max header table size to 0, but I don't see a way for the sender to clear the recipient's header table - that would be necessary to reset things if the sender did not send the HEADERS frame to the recipient and was unable to revert the header table to its previous state.

Michael Sweet, Senior Printing System Engineer, PWG Chair

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

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