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

Re: Recovery from decompression failure (was: Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues))

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 24 Jul 2014 06:12:18 -0700
Message-ID: <CABkgnnV82KWYVzHKNzFH7fXp4hZoC7vsqGsJcPDRep-O1qKuQQ@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, David Krauss <potswa@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>, Jason Greene <jason.greene@redhat.com>, Roberto Peon <grmocg@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
On 23 July 2014 17:55, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> So decoder changes table size only when it sees encodong context update? It
> works, but it has a disadvantage because decoder has to retain header table
> size unchanged until HEADERS/PP are received, which might never arrive.
> On the other hand, SETTINGS ACK is guaranteed to arrive (and we have a
> timeout for it). If decoder changes header table size, including eviction to
> the lowest value it advertised when it received SETTINGS ACK, encoder only
> sends its selected value based on the last seen value in SETTINGS decoder
> sent. This is because decoder already performed eviction based on the lowest
> value and encoding context update comes after SETTINGS ACK.

Yes, I would use SETTINGS ACK as the marker to use for trimming the
header table down, but still require the next header block after that
to include a context update.  That might mean two rounds of eviction
if the encoder chooses to use a smaller table size, but that's the
safest approach.
Received on Thursday, 24 July 2014 13:12:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:37 UTC