W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

RE: I ran across this while working on the spec.

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 17 Oct 2013 14:34:38 +0000
To: Fred Akalin <akalin@google.com>, Roberto Peon <fenix@google.com>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E52F50E989@ADELE.crf.canon.fr>
I'm wondering if we want to be able to clear out all compression state. We currently have 59 entries in the static table, meaning 8 bytes to store whether they are in the reference set or not.

I we want this, I think #1 is too complex.

It means that sending an index (therefore adding a new entry to the reference set) may trigger an eviction.

We have several other solutions for this:
- #2
- 3 Adding the possibility of clearing the reference set inside a header block.
- 4 Having a special rule for a max header table of 0, stating that this clears all the compression state.

My preference is for 2 or 3.


> -----Original Message-----
> From: Fred Akalin [mailto:akalin@google.com]
> Sent: jeudi 17 octobre 2013 04:10
> To: Roberto Peon
> Cc: ietf-http-wg@w3.org Group
> Subject: Re: I ran across this while working on the spec.
> (copying from issue)
> #1 <https://github.com/http2/http2-spec/issues/1>  has the problem that it
> introduces an ambiguity in what to do when reducing the max size (clear out
> the reference set first?). But if we specify exactly what to do when reducing
> the max size, then that isn't that bad.
> On Wed, Oct 16, 2013 at 5:37 PM, Roberto Peon <fenix@google.com> wrote:
> 	https://github.com/http2/http2-spec/issues/281

> 	Setting the max header size to 0 does not clear out all encoder state.
> 	In particular, elements to the reference set that are pointing to static
> table elements are not cleared out.
> 	There are a couple of obvious ways of fixing this:
> 	1) Include the space used in the reference set in the overhead (e.g.
> 2-bytes per reference)
> 	2) explicit SETTING for clearing the compression state
> 	I prefer #1.

Received on Thursday, 17 October 2013 14:35:14 UTC

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