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

Re: All changes but huffman encoding integrated + a question

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 17 Oct 2013 10:59:21 -0700
Message-ID: <CAP+FsNf9nexZn4y+AADpBu2dmn3zn9VdKcpTjX80HAbbyBChCg@mail.gmail.com>
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC