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: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 23 Jul 2014 09:50:23 +0900
Message-ID: <CAPyZ6=JvQck4TLnAtQ2chyEeJbOY9LT-SE6KWDrbiy-gc1zhQA@mail.gmail.com>
To: Martin Thomson <martin.thomson@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>
2014/07/23 1:45 "Martin Thomson" <martin.thomson@gmail.com>:
> On 22 July 2014 09:29, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> > If 2 SETTINGS_HEADER_TABLE_SIZE is in SETTINGS, say 0 and N in this
> > do we have to encode 2 encoding context update for both 0 and N or for
> > N?
> This needs clarification, because it's only implicit currently.  You
> need to include the lowest and highest values you have seen in
> settings when sending the next frame.
> https://github.com/http2/http2-spec/issues/565

We need to also clarify when first header table size change applies: a)
reception of SETTINGS (and its ACK) or b) encoding context update.
My understanding is a). The receiver of SETTINGS processes the setting
values in the order they appear in a frame and shrinking header table size
necessary. Then it can send encoding context update only for last seen
table size value.  This is possible because receiver of SETTINGS ACK also
applies its pending settings in the same way.  It then validates the
received encoding context update against last seen value and applies table
size again.  This is simpler than multiple encodong context update because
we just renember and validate 1 value instead of 2.

Best regards,
Tatsuhiro Tsujikawa
Received on Wednesday, 23 July 2014 00:50:50 UTC

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