- From: Roberto Peon <grmocg@gmail.com>
- Date: Mon, 2 Jun 2014 11:26:53 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNctRrXsjnWqwcZCY4+dFYpJvaSy6bH+wi3dC3PTPg5FWw@mail.gmail.com>
Any time it is indexed, a copy gets put into the header table, eventually expunging something. The spec requires that stored references are only to entries in the header table. These two couple to give the guarantee about reference set size. This is supposed to be the relevant chunk (from section 3.1.3), which can perhaps be made clearer? To limit the memory requirements on the decoder side for handling the reference set, only entries within the header table can be contained in the reference set. To still allow entries from the static table to take advantage of the differential encoding, when a header field is represented as a reference to an entry of the static table, this entry is inserted into the header table (see Section 3.2.1 <http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-07#section-3.2.1>). -=R On Mon, Jun 2, 2014 at 10:59 AM, Greg Wilkins <gregw@intalio.com> wrote: > > Guys, > > thanks for the explanations. I think I kind of understand now, although I > don't think it really looks "much cleaner" to the proverbial fresh eyes. > > Note that I'm not all that worried about the occasional resend of a static > index, or the copy or even the reference set size. My concern is simply > that a moderately complex design is well justified, well explained and > actually achieves the purpose for which it was intended. > > To paraphrase the responses to ensure that I've got it, the decision to > copy references to static entries to the dynamic table was done so that a > limit on the header table size is also effectively a limit on the reference > set. > > In extreme, if the header table size is set to 0, then the reference set > will also have to be empty because there will be no entries for it to > reference. Known headers will still be able to be sent as index's into > the static table, they will just never make it into the reference set > because they will never fit into the header table. > > However, I'm not so sure that this solution really does limit the size of > the reference set, because it can contain duplicates. Let say that the > header table has exactly one entry in it, then there is nothing to stop a > header block sending repeated references to it so that the reference set > become arbitrarily large with duplicate references? Personally I'm in > favour of limiting headers to one frame, so that would have an implicit > limit on the size of the reference set as you can only fit in so many index > references into one frame. > > cheers > > PS. Anybody care to explain why the static index's are on top of the > dynamic index's? Is this simply to try to ensure that the dynamic > references are more likely to fit into a 7+bit integer once they are copied? > > > > > > > > > > > > > > > > > > On 2 June 2014 18:59, Roberto Peon <grmocg@gmail.com> wrote: > >> 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. >>>> >>> >>> >> > > > -- > 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 18:27:21 UTC