Re: HEADERS and flow control

On Mon, May 19, 2014 at 11:50 PM, 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!
>
>
​We need to take into account connection-level flow control.  It is easily
exhausted and we certainly hit its barrier while sending any size of
HEADERS​ if they are flow controlled.

Best regards,
Tatsuhiro Tsujikawa




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