Re: Stream State and PRIORITY Frames

[Benedikt Christoph Wolters <[e-mail]>]

This question reminds me of a similiar issue we had a while ago at
mitmproxy: https://github.com/mitmproxy/mitmproxy/issues/1498

As far as I understand this, sending PRIORITY does not initiate a
stream or change the stream state.
HEADERS and PUSH_PROMISE initiate a stream. PRIORITY can be sent and
received in any stream state.

2017-01-17 7:32 GMT+01:00 Scott Mitchell <[e-mail]>:
> (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])?
>
> [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.
>
> [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.
>