Re: hpack static table question?

Lemme try to explain the whole thing :)
1) Every header table entry has an 'overhead' associated with it, thus even
zero-length strings have size.
2) Every entry always points to a header table entry (thus,has a
cost-in-bytes associated)
3) Every entry in the reference set is unique-- there is no way to have a
duplicate in there.

In your example:
index 4 becomes a reference to the first entry in the table.
Each duplicate reference causes the previous first entry to be evicted and
replaced.
Lets assume that the max-table-size is 42 here.
Since the cost-in-bytes of the entry are (strlen(":path") + strlen("/") +
32) == 38, one entry fits into the table, but two do not. Referencing the
static index again will cause the previous entry in the table to be evicted.
Referencing the header-table entry will cause it to be removed if it is
already present, and added if it isn't.
Any time an entry is removed from the header table, the reference to it in
the reference set must be removed (can't have dangling references!).

-=R


On Mon, Jun 2, 2014 at 12:18 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> Roberto,
>
> that clause from 3.1.3 is clear enough in what an impl must do, I just
> don't see how it achieve a limit on the reference set size.
>
> Consider a setup that has a small header table size that will fit just a
> single field into in.  This decoder then receives a header frame that
> contains a reference to header 4 (static :path:/).  This is copied into the
> header table at index 1 (evicting anything else that was in there) and is
> added to the reference set.  Now say that the rest of the header frame is
> full of many many duplicates of a reference to index 1.  For each reference
> another entry is made into the reference set pointing to the copied static
> entry.    This can continue for ever and represents unlimited growth of the
> reference set.
>
> If this kind of duplicate attack is not a problem, then I don't think we
> need to limit the size of the reference set, because without such
> duplicates, then every entry in the reference set is going to be much
> smaller than each entry in the header set.   Thus a limit on the header set
> size is effectively a limit on the reference set size, without the need to
> copy.
>
> So either I'm still missing something or this a complex mechanism that
> does not achieve what it is intended to do.
>
> 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.
>