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

RE: All changes but huffman encoding integrated + a question

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 17 Oct 2013 14:43:59 +0000
To: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E52F50E9A3@ADELE.crf.canon.fr>
I think that these two resolutions are linked to the order in which eviction and addition occurs.

In 1), we add, then evict.

In 2), we evict, then add.

The current spec states 2), without a clearly specifying what an index for the header name means when there is an eviction.

1) may be slightly easier for the encoder, but is slightly more complex for a decoder.
1) would also make the spec slightly easier to read.

I've no strong opinion one way or another.


> -----Original Message-----
> From: Roberto Peon [mailto:grmocg@gmail.com]
> Sent: mercredi 16 octobre 2013 04:25
> To: HTTP Working Group
> Subject: All changes but huffman encoding integrated + a question
> Just wanted to let people know that the github version of the compression
> spec includes all issues but huffman encoding (Herve and Jeff-- thanks)!
> I believe there is a potential ambiguity though, which I'm not sure if people
> realize or care about (and so asking here before potentially throwing mud in
> clear water)...
> When adding a new header to the header table, one must first evict entries.
> When using the indexed-name literal header representation, it is possible
> that one may be evicting the entry that contains the name which the new
> addition would need (and which needed to be examined in order to
> determine the amount of space to free up in the first place).
> There are two obvious resolutions:
> 1) Require that the name be kept in these circumstances (possibly by copying
> somewhere (ideally into the end of the buffer)). If the storage for the
> header table was a ring buffer, one would simply increment the '0' index
> without copying.
> This is my preference.
> 2) Make this illegal; This makes the encoder more complex as the encoder
> must attempt to do this encoding and then check to see if actually fit every
> time it does this kind of header representation.
> What do people think?
> -=R
Received on Thursday, 17 October 2013 14:44:34 UTC

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