Draft: draft-ietf-quic-http

Commentary: Expands on error handling discussion and clarifies difference from HTTP status codes which indicate error response . Also , some editorial consistency fixes : The references to errors seem to have missed our switch to use " ; see  . " where possible . Somewhere along the way , we stopped referring to the error handling section when defining errors . I 've done a sweep and believe these are consistent now . your review would be appreciated . 
 In the HTTP genart review , writes : H3REQUESTINCOMPLETE or H3NOERROR - Are these a separate concept from HTTP response status codes such as " 200 OK " and " 404 Not Found " , etc . ? Are these error codes related to QUIC errors ? Is the " application error code " mentioned in Section 5.3 the same concept or is it a different concept ? Is the " application error code " an HTTP/3 concept of a QUIC concept ? Is " connection error " used in Section 7 the same concept or is it a difference concept ? Does a " connection error " as used in Section 7 always mean that the entire connection fails , as opposed to a single stream ? Section 8 aims to explain some of these concepts , and I think the document should reference to this section for more information when it starts mentioning all these different error types . ( Or , if they are all the same , perhaps the terminology should be unified . ) 
 As you note , Section 8 describes the types of error , but mostly defers to QUIC - TRANSPORT for that . It 's probably worth pulling some more context into this document . 
 lgtm thank mikeLooks good to me , thanks!one nit
Paragraph (version A):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED (errors).  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version B):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED; see errors.  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version A):
A server MAY send one or more PUSH_PROMISE frames (frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  PUSH_PROMISE frames are not permitted
on push streams; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
A server MAY send one or more PUSH_PROMISE frames (frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  PUSH_PROMISE frames are not permitted
on push streams; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED;
see errors.
Paragraph (version A):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response with the
error code H3_REQUEST_INCOMPLETE.
Paragraph (version B):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response with the
error code H3_REQUEST_INCOMPLETE; see errors.
Paragraph (version A):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other known frame type MUST be treated as a connection error
of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other known frame type MUST be treated as a connection error
of type H3_FRAME_UNEXPECTED; see errors.
Paragraph (version A):
A TCP connection error is signaled by abruptly terminating the
stream.  A proxy treats any error in the TCP connection, which
includes receiving a TCP segment with the RST bit set, as a stream
error of type H3_CONNECT_ERROR (http-error-codes).  Correspondingly,
if a proxy detects an error with the stream or the QUIC connection,
it MUST close the TCP connection.  If the underlying TCP
implementation permits it, the proxy SHOULD send a TCP segment with
the RST bit set.
Paragraph (version B):
A TCP connection error is signaled by abruptly terminating the
stream.  A proxy treats any error in the TCP connection, which
includes receiving a TCP segment with the RST bit set, as a stream
error of type H3_CONNECT_ERROR; see errors.  Correspondingly, if a
proxy detects an error with the stream or the QUIC connection, it
MUST close the TCP connection.  If the underlying TCP implementation
permits it, the proxy SHOULD send a TCP segment with the RST bit set.
Paragraph (version A):
The Push ID space begins at zero, and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR when no
MAX_PUSH_ID frame has been sent or when the stream references a Push
ID that is greater than the maximum Push ID.
Paragraph (version B):
The Push ID space begins at zero, and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR (errors) when
no MAX_PUSH_ID frame has been sent or when the stream references a
Push ID that is greater than the maximum Push ID.
Paragraph (version A):
An endpoint MAY send multiple GOAWAY frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another HTTP connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR.
Paragraph (version B):
An endpoint MAY send multiple GOAWAY frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another HTTP connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR;
see errors.
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 H3_STREAM_CREATION_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 H3_STREAM_CREATION_ERROR (errors) unless such an
extension has been negotiated.
Paragraph (version A):
error of type H3_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
error of type H3_CLOSED_CRITICAL_STREAM.  Connection errors are
described in errors.
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
H3_STREAM_CREATION_ERROR.
Paragraph (version A):
Each Push ID MUST only be used once in a push stream header.  If a
push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of
type H3_ID_ERROR.
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
H3_STREAM_CREATION_ERROR; see errors.
Paragraph (version B):
Each Push ID MUST only be used once in a push stream header.  If a
push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of
type H3_ID_ERROR; see errors.
Paragraph (version A):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error (errors) of type H3_FRAME_ERROR.
Paragraph (version A):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type H3_FRAME_ERROR.  Streams that terminate abruptly may be reset at
any point in a frame.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR; see errors.
Paragraph (version B):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error of type
H3_FRAME_ERROR; see errors.  Streams that terminate abruptly may be
reset at any point in a frame.
Paragraph (version A):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version A):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error (errors) of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version B):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version B):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
H3_FRAME_UNEXPECTED; see errors.
Paragraph (version A):
The GOAWAY frame applies to the entire connection, not a specific
stream.  A client MUST treat a GOAWAY frame on a stream other than
the control stream as a connection error (errors) of type
H3_FRAME_UNEXPECTED.
Paragraph (version B):
The GOAWAY frame applies to the entire connection, not a specific
stream.  A client MUST treat a GOAWAY frame on a stream other than
the control stream as a connection error of type H3_FRAME_UNEXPECTED;
see errors.
Paragraph (version A):
QUIC allows the application to abruptly terminate (reset) individual
streams or the entire connection; see Sections 2.4 and 5.3 of QUIC-
TRANSPORT.  These are referred to as "stream errors" or "connection
errors" (see Section 11 of QUIC-TRANSPORT) and have associated error
codes, but do not necessarily indicate a problem with the connection
or either implementation.  For example, a stream can be reset if the
requested resource is no longer needed.
Paragraph (version A):
An endpoint MAY choose to treat a stream error as a connection error
under certain circumstances.  Implementations need to consider the
impact on outstanding requests before making this choice.
Paragraph (version B):
When a stream cannot be completed successfully, QUIC allows the
application to abruptly terminate (reset) that stream and communicate
a reason; see Section 2.4 of QUIC-TRANSPORT.  This is referred to as
a "stream error."  An HTTP/3 implementation can decide to close a
QUIC stream and communicate the type of error.  Wire encodings of
error codes are defined in http-error-codes.  Stream errors are
distinct from HTTP status codes which indicate error conditions.
Stream errors indicate that the sender did not transfer or consume
the full request or response, while HTTP status codes indicate the
result of a request that was successfully received.
Paragraph (version B):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see Section 5.3 of QUIC-
TRANSPORT.  This is referred to as a "connection error."  Similar to
stream errors, an HTTP/3 implementation can terminate a QUIC
connection and communicate the reason using an error code from http-
error-codes.
Paragraph (version B):
Although the reasons for closing streams and connections are called
"errors," these actions do not necessarily indicate a problem with
the connection or either implementation.  For example, a stream can
be reset if the requested resource is no longer needed.
Paragraph (version B):
An endpoint MAY choose to treat a stream error as a connection error
under certain circumstances, closing the entire connection in
response to a condition on a single stream.  Implementations need to
consider the impact on outstanding requests before making this
choice.
Paragraph (version A):
This section describes HTTP/3-specific error codes that can be used
to express the cause of a connection or stream error.
Paragraph (version A):
An endpoint that does not monitor this behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error (errors) of
type H3_EXCESSIVE_LOAD, but false positives will result in disrupting
valid connections and requests.
Paragraph (version B):
An endpoint that does not monitor this behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error of type
H3_EXCESSIVE_LOAD (errors), but false positives will result in
disrupting valid connections and requests.