Re: Stream State and PRIORITY Frames

On Thu, Jan 19, 2017 at 7:55 AM, Patrick McManus <mcmanus@ducksong.com>
wrote:

>
>
> On Wed, Jan 18, 2017 at 7:53 PM, Scott Mitchell <scott.k.mitch1@gmail.com>
> wrote:
>
>>
>>
>> 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.
>>
>
> Yes, they are grouping nodes and serve no other purpose. I personally
> believe they are in the idle state, but I know some people believe they are
> closed with a priority attached. That doesn't seem to matter in practice.
>
>


The state transition I mentioned above is triggered by a HEADERS frame. So
far I have not heard any dispute over this. It seem to be clearly defined
in section 5.1.1 (see below). Do you have a different interpretation of
this section?

https://tools.ietf.org/html/rfc7540#section-5.1.1

The 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.  For example, if a client sends a
HEADERS frame on stream 7 without ever sending a frame on stream 5,
then stream 5 transitions to the "closed" state when the first frame
for stream 7 is sent or received.



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).
>>
>>
>
> So yes, and no. Certainly the server is in compliance in just ignoring
> everything it knows about priority indications from the client. OTOH,
> things can get very very screwed performance wise if dependencies are
> disregarded and the state of priority is just determined by the local
> weights on each stream. I've seen servers do this and create terrible
> results.
>
>

I'm not suggesting that servers should ignore priority, and I agree this
can be detrimental to page load times and general performance. My point was
meant to clarify the actual behavior of FF since it was used as an example
of "transitioning the stream state would be unexpected". The way FF
currently behaves these streams should be closed because a HEADERS frame is
used anyways.