Re: Header Size? Was: Our Schedule

On 31 May 2014 10:15, Greg Wilkins <gregw@intalio.com> wrote:

> Consider the example of merging two connection onto a connection, both
> coming from clients using large cookies.  With the current hpack, every
> time the merged connection switches from a stream from one connection to
> the other, it is going to have to removed the large cookies from the state
> table and send the other connection cookies (uncompressed because they are
> cookies).   This will be a rapid degradation in compression performance.



My apologies - I've talking a bit of nonsense on this proxy point.    As
I'm currently implementing hpack, it has dawned on me that it is possible
to remove a header from the reference set without removing it from the
header table (in fact you can't explicitly remove an entry from the header
table, you can only remove it by overflowing or resizing).

Thus my concern that a proxy merging multiple connections onto 1 connection
will end up retransmitting cookies frequently is wrong.   If the header
table is large enough, then fields from all the merged connections can
remain in the header table.  They will just be frequently added/deleted
from the reference set, using small indexed references in the header
block.  I don't see this as a significant problem.

Shows the value of working code... peddling fast as I can to catch up!

However, my concerns remain about the unconstrained size of the headers
that servers must hold; the fact that they are not flow controlled (which
will encourage the unconstrained size usage); that they cannot be
interleaved creating an easy DOS vector; that they must be processed
serially.  I also currently think it is worth evaluating separating the
transport meta-data from other meta data.

regards

-- 
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.