-
-A client sends an HTTP request on a request stream, which is a client-initiated
-bidirectional QUIC stream; see Section 6.1. A client MUST send only a
-single request on a given stream. A server sends zero or more interim HTTP
-responses on the same stream as the request, followed by a single final HTTP
-response, as detailed below. See Section 14 of [SEMANTICS] for a description
-of interim and final HTTP responses.¶
-Pushed responses are sent on a server-initiated unidirectional QUIC stream; see
-Section 6.2.2. A server sends zero or more interim HTTP responses, followed
-by a single final HTTP response, in the same manner as a standard response.
-Push is described in more detail in Section 4.4.¶
-On a given stream, receipt of multiple requests or receipt of an additional HTTP
-response following a final HTTP response MUST be treated as malformed
-(Section 4.1.3).¶
-An HTTP message (request or response) consists of:¶
-
-- the header field section, sent as a single HEADERS frame (see
-Section 7.2.2),¶
-
- - optionally, the payload body, if present, sent as a series of DATA frames
-(see Section 7.2.1), and¶
-
- - optionally, the trailer field section, if present, sent as a single HEADERS
-frame.¶
-
-
-Header and trailer field sections are described in Sections 5.4 and 5.6 of
-[SEMANTICS]; the payload body is described in Section 5.5.4 of
-[SEMANTICS].¶
-Receipt of an invalid sequence of frames MUST be treated as a connection error
-of type H3_FRAME_UNEXPECTED; see Section 8. 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 Section 9.¶
-A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5)
-before, after, or interleaved with the frames of a response message. These
-PUSH_PROMISE frames are not part of the response; see Section 4.4 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 Section 8.¶
-Frames of unknown types (Section 9), including reserved frames
-(Section 7.2.8) MAY be sent on a request or push stream before, after, or
-interleaved with other frames described in this section.¶
-The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic
-table. While these updates are not directly part of the message exchange, they
-must be received and processed before the message can be consumed. See
-Section 4.1.1 for more details.¶
-The "chunked" transfer encoding defined in Section 7.1 of [HTTP11] MUST NOT
-be used.¶
-A response MAY consist of multiple messages when and only when one or more
-interim responses (1xx; see Section 14.2 of [SEMANTICS]) precede a final
-response to the same request. Interim responses do not contain a payload body
-or trailers.¶
-An HTTP request/response exchange fully consumes a client-initiated
-bidirectional QUIC stream. After sending a request, a client MUST close the
-stream for sending. Unless using the CONNECT method (see Section 4.2), clients
-MUST NOT make stream closure dependent on receiving a response to their request.
-After sending a final response, the server MUST close the stream for sending. At
-this point, the QUIC stream is fully closed.¶
-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 Section 8.¶
-A server can send a complete response prior to the client sending an entire
-request if the response does not depend on any portion of the request that has
-not been sent and received. When the server does not need to receive the
-remainder of the request, it MAY abort reading the request stream, send a
-complete response, and cleanly close the sending part of the stream. The error
-code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on
-the request stream. Clients MUST NOT discard complete responses as a result of
-having their request terminated abruptly, though clients can always discard
-responses at their discretion for other reasons. If the server sends a partial
-or complete response but does not abort reading the request, clients SHOULD
-continue sending the body of the request and close the stream normally.¶
-
-
-
-
-Once a request stream has been opened, the request MAY be cancelled by either
-endpoint. Clients cancel requests if the response is no longer of interest;
-servers cancel requests if they are unable to or choose not to respond. When
-possible, it is RECOMMENDED that servers send an HTTP response with an
-appropriate status code rather than canceling a request it has already begun
-processing.¶
-Implementations SHOULD cancel requests by abruptly terminating any
-directions of a stream that are still open. This means resetting the
-sending parts of streams and aborting reading on receiving parts of streams;
-see Section 2.4 of [QUIC-TRANSPORT].¶
-When the server cancels a request without performing any application processing,
-the request is considered "rejected." The server SHOULD abort its response
-stream with the error code H3_REQUEST_REJECTED. In this context, "processed"
-means that some data from the stream was passed to some higher layer of software
-that might have taken some action as a result. The client can treat requests
-rejected by the server as though they had never been sent at all, thereby
-allowing them to be retried later.¶
-Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were
-partially or fully processed. When a server abandons a response after partial
-processing, it SHOULD abort its response stream with the error code
-H3_REQUEST_CANCELLED.¶
-Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests. Upon
-receipt of this error code, a server MAY abruptly terminate the response using
-the error code H3_REQUEST_REJECTED if no processing was performed. Clients MUST
-NOT use the H3_REQUEST_REJECTED error code, except when a server has requested
-closure of the request stream with this error code.¶
-If a stream is canceled after receiving a complete response, the client MAY
-ignore the cancellation and use the response. However, if a stream is cancelled
-after receiving a partial response, the response SHOULD NOT be used. Only
-idempotent actions such as GET, PUT, or DELETE can be safely retried; a client
-SHOULD NOT automatically retry a request with a non-idempotent method unless it
-has some means to know that the request semantics are idempotent
-independent of the method or some means to detect that the original request was
-never applied. See Section 8.2.2 of [SEMANTICS] for more details.¶
-
-