Re: All changes but huffman encoding integrated + a question

Add-then-evict generally implies that the amount of memory consumed is
potentially 2X the stated max size.
The proposed #1 boils down more to Evict or Move, then Add
-=R


On Thu, Oct 17, 2013 at 7:43 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

> 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.
>
> Hervé.
>
> > -----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 17:59:49 UTC