W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: 6.5.2 FLOW_CONTROL_OPTIONS text

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 23 Jul 2013 15:20:26 -0700
Message-ID: <CABkgnnWU+6-XUnjtMY7_n2nceJ_7i+tj4rMvb6RPrTMsRGT+ww@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Yep, I can see how that would be confusing.

The intent was: bit 0x1 == 0 => flow control as before; bit 0x1 == 1
=> stop flow control.

https://github.com/http2/http2-spec/issues/181

I've marked it as editorial, but maybe we should discuss what we want
from this a little more.

On 23 July 2013 14:00, Patrick McManus <pmcmanus@mozilla.com> wrote:
> I found this really confusing:
>
>   SETTINGS_FLOW_CONTROL_OPTIONS (10):  indicates that streams directed
>       to the sender will not be subject to flow control.  The least
>       significant bit (0x1) of the value is set to indicate that new
>       streams are not flow controlled.  All other bits are reserved.
>
>       This setting applies to all streams, including existing streams.
>
>       These bits cannot be cleared once set, see Section 6.9.4.
>
>
> 1] does the value always need to be 1? The option as a whole is defined to
> indicate that "streams .. will not be subject to flow control" - so not
> setting the value would seem to be inconsistent. But if the value can only
> be 1, why define a value at all? Maybe the option definition is misleading
> and should be "whether or not streams will be subject to flow control"?
>
> 2] "This setting applies to all streams, including existing ones".. but the
> "value is set to indicate that new streams are not flow controlled"
> (implying existing streams are not impacted).
>
> 3] "These bits cannot be..".. bits is plural, but only 1 bit is defined.
>
> barring better advice, for my -04 implementation I am going to test the low
> bit of the value, and if true apply the logic to all present and future
> sends directed to the sender of the option.
Received on Tuesday, 23 July 2013 22:20:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC