- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 19 May 2014 08:10:06 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
It will be fairly trivial to do all kinds of things to bypass the flow control the way things are currently defined. The right way to address this is to have a clear delineation between frames that are always hop-by-hop (control) vs. end-to-end (data) and to always require end-to-end headers to be flow controlled. Making this distinction now will make it easier later when someone decides to extend the protocol to do more interesting things beyond just HTTP (like Roberto suggested at the start of this thread and like I suggested last year). On Mon, May 19, 2014 at 7:50 AM, Greg Wilkins <gregw@intalio.com> wrote: > 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.
Received on Monday, 19 May 2014 15:10:58 UTC