Draft: draft-ietf-quic-http

Commentary: There are presently several kinds of very similar error when creating streams : MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer . It is not a connection error . MUST be used if a peer tries to open more than one critical stream ( control , QPACK ) . Connection error . MUST be used if a client tries to open a push stream . More generally this could be used if a peer attempts to open a stream type that is not allowed to , but push is the only example today . Connection error . The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION . The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop . PS . The eagle eyes will notice I omitted the HTTPDUPLICATEPUSH creation error . This is on the chopping block in . I class it differently because it is about parsing information after the stream type . 
 Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream ? At the moment the designated error code is HTTPGENERALPROTOCOLERROR , but STREAMCREATIONERROR might be a better fit . Or if we are not going to use STREAMCREATIONERROR for server - initiated bidirectional streams , I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion . 
 This relates to some earlier discussion on and its now - merged PR We only recently text to specify the use of HTTPGENERALPROTOCOLERROR in this case , I think it fits to modify this to STREAMCREATION_ERROR . 
 Changed in
Paragraph (version A):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection
error of type HTTP_GENERAL_PROTOCOL_ERROR unless such an extension
has been negotiated.
Paragraph (version B):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection
error of type HTTP_STREAM_CREATION_ERROR unless such an extension has
been negotiated.
Paragraph (version A):
If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown.  Recipients of unknown stream types MAY
trigger a QUIC STOP_SENDING frame with an error code of
HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be a
connection error of any kind.
Paragraph (version B):
If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown.  Recipients of unknown stream types MAY
trigger a QUIC STOP_SENDING frame with an error code of
HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be
a connection error of any kind.
Paragraph (version A):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS.  Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control
stream, and the receiver MUST NOT request that the sender close the
control stream.  If either control stream is closed at any point,
this MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS.  Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type
HTTP_STREAM_CREATION_ERROR.  The sender MUST NOT close the control
stream, and the receiver MUST NOT request that the sender close the
control stream.  If either control stream is closed at any point,
this MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Paragraph (version A):
Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a connection error of type
HTTP_WRONG_STREAM_DIRECTION.
Paragraph (version B):
Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a connection error of type
HTTP_STREAM_CREATION_ERROR.
Paragraph (version A):
A unidirectional stream header contained an unknown stream type.
Paragraph (version A):
A unidirectional stream type was used more times than is permitted
by that type.
Paragraph (version A):
A unidirectional stream type was used by a peer which is not
permitted to do so.
Paragraph (version B):
The endpoint detected that its peer created a stream that it will
not accept.