Re: Stream State and PRIORITY Frames

On Tue, Jan 17, 2017 at 2:43 PM, Scott Mitchell <scott.k.mitch1@gmail.com>
wrote:

> From my perspective I would like to see two clarifications:
>
> 1. It is clear to me that PRIORITY doesn't impact state. However Section
> 5.1.1 states "first use of a new stream identifier" which makes no
> reference to stream state. If stream state is important/implied here better
> to be specific about it. I don't think the one-off example below this text
> is sufficient to convey the intended implications of this statement.
>
> 2. Section 5.1.2 states "Streams in either of the 'reserved' states do
> not count toward the stream limit." which seems to conflict with section
> 8.2.2 "A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to
> limit the number of responses that can be concurrently pushed by a server.".
> These two statements appear to contradict each other. Since
> SETTINGS_MAX_CONCURRENT_STREAMS is really the only mechanism to limit
> resources due to server push I'm assuming section 5.1.2 is overly
> restrictive.
>

This is surprising (to me, at least) but I don't believe there is a
contradiction. You can send an infinite number of PUSH_PROMISEs without
hitting SETTINGS_MAX_CONCURRENT_STREAMS. A pushed stream doesn't count
against the concurrent stream limit until you've sent the response HEADERS
on that pushed stream. See the related question I asked previously:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0599.html


> On Tue, Jan 17, 2017 at 2:27 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> On 18 January 2017 at 01:37, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
>> wrote:
>> > If my understanding is correct, this only refers to the new stream ID
>> used
>> > by HEADERS, and PUSH_PROMISE frames which open or reserve streams.  The
>> > example text following that statement uses HEADERS which opens new
>> stream.
>> > PRIORITY frame does not change stream state, and there is no reason to
>> close
>> > all unused streams lower than bearing stream ID.  That said, I agree
>> that
>> > this is not crystal clear in the document.  In practice, this is
>> probably
>> > rather rare case.
>>
>> This is, I think, the expectation.
>>
>> I think that we probably want to clarify the point by explicitly
>> saying that PRIORITY doesn't affect stream states.  We say that it can
>> be sent in any state, but we don't also mention that important point.
>> Do people here agree that an erratum on this point is appropriate
>> here?
>>
>
>