- From: Roberto Peon <grmocg@gmail.com>
- Date: Mon, 2 Jun 2014 09:59:16 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNfSJx-gbM147uLdZMuoYWtYXzCvdSw81y74zufogxBtkQ@mail.gmail.com>
To expand on what Herve (and I) were saying, by treating these static headers like all other headers, the size of the reference set becomes constrained by the total memory size, and thus an implementation can cause the state to be cleared, or never allocated while allowing indexed representations to be used by the encoder. Additionally, assuming one doesn't optimize the copying away (which is certainly possible) it becomes possible to use a circular buffer to hold all of the data in the compressor. This reduces memory fragmentation and can improve CPU cache latency. IIRC, this was put in 2 or 3 drafts ago. It seemed much cleaner than dealing with multiple thresholds (one for ref data, one for memory). -=R On Mon, Jun 2, 2014 at 9:54 AM, Roberto Peon <grmocg@gmail.com> wrote: > This was for safety. This ensures that entries in the reference set get > counted, even if the reference set is composed solely of members from the > static table. > > This method was the simplest method for doing so. > > -=R > > > On Mon, Jun 2, 2014 at 7:45 AM, Greg Wilkins <gregw@intalio.com> wrote: > >> >> The hpack draft 7 says in 3.2.1 : "The referenced static entry is >> inserted at the beginning of the header table". >> >> I can't understand why this copy of a static entry to the dynamic table >> is needed? Doesn't this mean that the static entry will now be known by >> two indexes? Why is this copy needed? Also If a badly written encoder >> kept sending the static index reference, then it would be possible to fill >> up the header table with duplicates of the static header? >> >> I'm also struggling to work out why the indexing is done like: >> >> <---------- Index Address Space ----------> >> <-- Header Table --> <-- Static Table --> >> +---+-----------+---+ +---+-----------+---+ >> | 1 | ... | k | |k+1| ... | n | >> +---+-----------+---+ +---+-----------+---+ >> ^ | >> | V >> Insertion Point Drop Point >> >> >> I would have thought it better to have the tables as: >> >> <---------- Index Address Space ----------> >> <-- Static Table --> <-- Header Table --> >> +---+-----------+---+ +---+-----------+---+ >> | 1 | ... | k | |k+1| ... | n | >> +---+-----------+---+ +---+-----------+---+ >> ^ | >> | V >> Insertion Point Drop Point >> >> >> This looks like a very deliberate decision made for good reason... but >> the reason alludes me at the moment. >> >> cheers >> >> >> >> >> >> >> >> >> >> -- >> Greg Wilkins <gregw@intalio.com> >> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that >> scales >> http://www.webtide.com advice and support for jetty and cometd. >> > >
Received on Monday, 2 June 2014 16:59:43 UTC