Re: HEADERS and flow control

If the protocol does not apply flow controlled to headers, then somebody
will eventually abuse this as a way to get around flow control and start
sending bulk data as headers rather than data.   Once a few start doing it,
then it will become main stream.

This is exactly what happened with browsers switching to using 6
connections instead of 2, because some started to do it to improve their
speed.  It started with individuals changing their own browsers, but then
eventually one browser switched and everybody had to follow to stay
competitive no matter how badly it abused the protocol!

Other than the meta data defined by HTTP, all other headers are essentially
application data and must be flow controlled.

The deadlock scenario described is only a problem if the initial compressed
headers are larger than the initial flow control window, which at 64kB is
highly unlikely with current usage.  However, if we don't put flow control
on headers, then I think we will very soon start seeing >64kB headers!

I definitely support putting flow control on all non control frames within
a stream.   If this means we have to do something a bit ugly to avoid the
deadlock, then I think that is far better than unconstrained meta-data.











On 19 May 2014 09:41, Mark Nottingham <mnot@mnot.net> wrote:

> Roberto,
>
> I’ve opened <https://github.com/http2/http2-spec/issues/480> to track
> this.
>
> We’ll discuss this in NYC (although please do continue discussing on-list).
>
> Be warned that a large amount of the discussion around this will be “Is
> this worth holding HTTP/2 for another implementation draft / implementation
> / interop cycle?”
>
> Cheers,
>
>
>
> On 10 May 2014, at 4:42 am, 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.
> >
> > One of the potential users of HTTP2 whom I've spoken with wished
> strongly that HEADERS after the first complete HEADERS block on a stream
> would be subject to flow control. AFAICT, this would work better than what
> we have today, without potentially triggering the deadlock scenario for
> many non-browser usecases.
> >
> > Thoughts?
> >
> > -=R
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>


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