H2 HEADERS and flow control

No I'm not intending to start the whole debate on this again..... I just
have a question on one aspect.

I totally accept that we cannot flow control headers whilst we have a
mutable shared state table, and I pretty much accept the benefits of said
shared mutable state table in this incarnation of the protocol.

But why can't we at least deduct the header frame sizes from the available
window size, so that a stream that is sending a lot of data in headers does
not necessarily get more share of the connection.

Simple example is that if a response is sent starting with a 16KB HEADERS
and a 10KB CONTINUATION, then instead of the data frames having a 64KB
window, they will be left with a 48KB window.

The caveats will of course have to be that a header/continuation frame will
not be able to reduce the window below 0, nor shall it be prevented from
being sent if the window is zero.   Thus of a 256KB header is sent, the
stream window will be zero, but the 7 continuation frames will all get
sent, but the stream will stall on the first data frame waiting for a
window update.

If we accept that most implementations will have a limit on header size
<=16KB for 99.99% of users, then including the header frame sizes in the
window accounting will at least remove the incentive for applications to
move data to the headers to avoid flow control.  Ie sending headers will
still have a cost - only that it is paid by your data frames rather than
your headers/continuations.

Has this been considered before?

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.