Stream State and PRIORITY Frames

(originally posted here:

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 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])?

> 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.

> An endpoint that
   receives an unexpected stream identifier MUST respond with a
   connection error (Section 5.4.1) of type PROTOCOL_ERROR.

Received on Tuesday, 17 January 2017 06:32:51 UTC