Re: Stream State and PRIORITY Frames

On Wed, Jan 18, 2017 at 11:50 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> On 18 Jan 2017, at 16:38, Scott Mitchell <scott.k.mitch1@gmail.com> wrote:
>
> This is interesting. If FF is using streams 1-7 then as soon as stream 9
> is used for a HEADERS request that will close streams 1-7 according to
> section 5.1.1:
>
> > first use of a new stream identifier implicitly closes all streams in
> the "idle" state that might have been initiated by that peer with a
> lower-valued stream identifier
>
>
> Only if they are not opened via HEADERS frames, which they are. FF sent (I
> haven’t checked recently) PRIORITY frames for the first few stream IDs, and
> then started sending HEADERS from 1 onwards.
>
>
>

I just ran FF 50.1.0 against a simple local server (TLS+ALPN) and here is
the behavior I observe:

1. Client PRIORITY [StreamId=3,StreamDependency=0,
Weight=201,Exclusive=False] -> Server
2. Client PRIORITY [StreamId=5,StreamDependency=0,
Weight=101,Exclusive=False] -> Server
3. Client PRIORITY [StreamId=7,StreamDependency=0,
Weight=1,Exclusive=False] -> Server
4. Client PRIORITY [StreamId=9,StreamDependency=7,
Weight=1,Exclusive=False] -> Server
5. Client PRIORITY [StreamId=11,StreamDependency=3,
Weight=1,Exclusive=False] -> Server
6. Client HEADERS [StreamId=13,StreamDependency=11,
Weight=2,Exclusive=False] -> Server (a GET "/" request)
7. Client HEADERS [StreamId=15,StreamDependency=0,
Weight=16,Exclusive=False] -> Server (a GET "/favicon.ico" request)

There were other frames (SETTINGS, DATA, PING, WINDOW_UPDATE, GO_AWAY)
which were omitted for the purposes of this discussion.

Based on the RFC it seems like stream ids {3, 5, 7, 11} should be closed at
step (6). Note that FF is not doing anything wrong here. It shouldn't have
to care that the streams are CLOSED in this scenario (assuming these
streams only ever have PRIORITY frames exchanged). It would be interesting
to get a FF dev to comment on the expected stream state here just to be
sure these streams will only be used for PRIORITY. Either way
maintaining/interpreting the priority is at the discretion of the server
and these streams being closed does not impact the server's ability to do
this (as discussed previously the RFC suggests retaining priority for
closed streams).


Cory
>
>