Re: Stream State and PRIORITY Frames

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

On Tue, Jan 17, 2017 at 3:32 PM, Scott Mitchell <[e-mail]>
wrote:

> (originally posted here: https://github.com/http2/http2-spec/issues/759)
>
> What is the expected result in terms of stream state and any potential
> errors that should be generated from the following scenario:
>
> ```
> 1. Client [PRIORITY, id: 5] -> Server
> 2. Client [HEADERS, id: 3] -> Server
> ```
>
> ## Option 1
> The server accepts both frames. Stream `3` is OPEN and stream `5` remains
> in IDLE.
>
> This behavior is verified in the h2spec verification tool via
> https://github.com/summerwind/h2spec/pull/67. Also see additional
> discussion there.
>
> ## Option 2
> Should the use of stream ID `5` cause stream ID `3` (and all lower stream
> IDs) to be implicitly closed according to the section-5.1.1 (see [1])? This
> would mean after the server receives the frame from step (1) it thinks that
> stream ID `3` has been closed, and when the server receives the frame from
> step (2) it will respond with a connection error of type PROTOCOL_ERROR
> (see [2])?
>
>
​
​I think Option 1 is the expected result.


> [1] 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.
>
>
​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.

Best regards,
Tatsuhiro Tsujikawa



> [2] https://tools.ietf.org/html/rfc7540#section-5.1.1
> > An endpoint that
>    receives an unexpected stream identifier MUST respond with a
>    connection error (Section 5.4.1) of type PROTOCOL_ERROR.
>
>