Draft: draft-ietf-quic-http

Commentary: Clarify HTTP message definition . Require the connection to be closed upon receipt of frames in incorrect order . Refer to HTTP messages in push stream section . This addresses 
 Good catch . I a paragraph to explicitly allow unknown frames to the message exchange section . I also modified the wording in the push section to be more permissive of interleaved frames ( " by " instead of " consists of " ) . 
 LGTM 
 According to , a bidirectional HTTP stream can have at least one HEADERS frame ( exactly one if the stream is client - initiated ) , zero or more DATA frames , then zero or one HEADERS frame , in this order . Handling the receipt of frames that does not conform to this requirement is inconsistent : ( 1 ) If a DATA frame is received before any other frame , that 's an error : ( 2 ) If the trailing HEADERS frame is followed by another HEADERS frame , that is to be discarded : ( 3 ) There is no guidance on how to handle a DATA frame after the trailing headers . I suggest that every violation to this requirement should be an error . ( I do not feel strongly whether a connection error like ( 1 ) is handled right now , or a stream error . The implementation I am contributing to will promote most stream errors to connection errors regardless . ) Note that ( 2 ) comes from the technical limitation that header blocks needed to be processed , which is not the case any longer with QPACK . It just seems like that when the requirement to decode the header block was removed at , adding the requirement to signal an error was not in scope of that commit . 
 I agree with . If you read that requirement a certain way , then any use of trailers will blow up the connection :) I think we could rewrite this text to be clearer about when DATA frames are expected to be received . 
 Good points . Let 's continue tightening down the screws . :-) 
 Closed in . 
 This text was already somewhat lacking by not discussing the possibility of extension frames being interleaved ; stating that the push stream consists of " responses " rather than " frames " extends this shortcoming to the push stream section . I 'm open to fixing this in a separate PR , if you prefer , though .
Paragraph (version A):
the payload body (see RFC7230, Section 3.3), sent as a series of
DATA frames (see frame-data),
Paragraph (version A):
optionally, one HEADERS frame containing the trailer-part, if
present (see RFC7230, Section 4.1.2).
Paragraph (version B):
optionally, the payload body, if present (see RFC7230,
Section 3.3), sent as a series of DATA frames (see frame-data),
Paragraph (version B):
optionally, trailing headers, if present (see RFC7230,
Section 4.1.2), sent as a single HEADERS frame.
Paragraph (version B):
Frames of unknown types (extensions), including reserved frames
(frame-grease) MAY be sent on a request or push stream before, after,
or interleaved with other frames described in this section.
Paragraph (version A):
If a DATA frame is received before a HEADERS frame on a either a
request or push stream, the recipient MUST respond with a connection
error of type HTTP_UNEXPECTED_FRAME (errors).
Paragraph (version A):
Trailing header fields are carried in an additional HEADERS frame
following the body.  Senders MUST send only one HEADERS frame in the
trailers section; receivers MUST discard any subsequent HEADERS
frames.
Paragraph (version B):
If an endpoint receives an invalid sequence of frames on either a
request or a push stream, it MUST respond with a connection error of
type HTTP_UNEXPECTED_FRAME (errors).  In particular, a DATA frame
before any HEADERS frame, or a HEADERS or DATA frame after the
trailing HEADERS frame is considered invalid.
Paragraph (version A):
A push stream is indicated by a stream type of "0x01", followed by
the Push ID of the promise that it fulfills, encoded as a variable-
length integer.  The remaining data on this stream consists of HTTP/3
frames, as defined in frames, and fulfills a promised server push.
Server push and Push IDs are described in server-push.
Paragraph (version B):
A push stream is indicated by a stream type of "0x01", followed by
the Push ID of the promise that it fulfills, encoded as a variable-
length integer.  The remaining data on this stream consists of HTTP/3
frames, as defined in frames, and fulfills a promised server push by
zero or more non-final HTTP responses followed by a single final HTTP
response, as defined in request-response.  Server push and Push IDs
are described in server-push.