- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 18 Jul 2014 14:37:57 -0500
- To: Michael Sweet <msweet@apple.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Jul 18, 2014, at 2:28 PM, Michael Sweet <msweet@apple.com> wrote: > Martin, > > 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. I think he’s referring to the encoding context update instruction in HPACK itself. So I guess you could just set the table to 0 and back to 4096 in the next HEADERS frame. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 18 July 2014 19:38:28 UTC