Re: #540 jumbo frame, was: Stuck in a train -- reading HTTP/2 draft.

On 24 June 2014 20:48, <K.Morgan@iaea.org> wrote:

>
> > Note that it does not allow headers to be flow controlled - so it is not
> a perfect solution to all the issues raised
> > about headers.
>
> Why not (meaning, why can't they be flow controlled)?


Because you only know how much of the available window will be consumed by
the send  after you have have encoded the header frame.  Once you have
encoded it with hpack, then you have to send it, so the mutations to the
shared state table will not correctly applied and subsequent encoded frames
can be decoded.

You can't even calculate the encoded size without actually mutating the
table, because the table changes during encoding.  Also the eventual size
when encoded may (and often will be) significantly different depending on
the state of the table after the compression of other frames.

Once encoded with hpack, a frame must be sent, so you cannot apply flow
control to it, without controlling the flow of all headers.

The only solution is to either not have delta encoding (a big loss) or to
not have a single and/or mutable state table.

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.