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