Re: HEADERS and flow control

On 9 May 2014 20:42, Roberto Peon <grmocg@gmail.com> wrote:

> Currently HEADERS are not subject to flow control. There are a couple of
> reasons for this, but the biggest one is that this helps to prevent a
> deadlock which can occur when a server is waiting for a particular
> request before it can make progress on other responses, but flow control is
> asserted.
>


Circling back on this one!

Excluding HEADERS from flow control doesn't prevent deadlock.   If the
request that the server is waiting on is a post with a body and the
connection window is consumed, then we are deadlocked just the same.

Flow control is intended to limit the resources that a server needs to
commit to a stream/connection. So exempting headers just gives an incentive
to put more data in them, to thus consume more server resources and thus
increase the chances of once stream interacting with another.

Big data is not a problem for a server, as you only have to read a little
bit of it at a time and stream it to the application (which may decide to
aggregate, but that is somebody else design decision).  Big headers are a
big resource commitment for servers as we must hold them for the entire
duration of the request handling.

So if a server accepts >64KB of headers on a stream, it has to hold those
for the entire duration of the request handling as the application can ask
for a header at any time.  Even if the request handling suspends and waits
a long time for some downstream service, the headers have to be held.

To me, this is just like the browsers unilaterally deciding to break the
two connection rule, regardless of the impact on server resources, except
in this case at least servers have the ability to say no.  However, if
browser vendors decide to allow larger headers to be sent and large
corporations with big budgets are accepting of those headers, this will
have a big resource impact on the rest of use.   Sorry for my "flair for
the dramatic", but this goes somewhat towards network neutrality as we
should not be designing a protocol that will only scale for those with big
budgets!

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.