]>

martenseemann@gmail.com

Web and Internet Transport HTTP QUIC stream resets do not guarantee delivery of stream data sent before the reset. This is a problem for HTTP/3 when the correct protocol outcome is an abrupt stream termination, but the sender still has a bounded prefix worth delivering, such as response headers, a short diagnostic response body, or a partial response received from an upstream host. RESET_STREAM_AT provides reliable delivery of that prefix and is already used by WebTransport over HTTP/3 when resetting streams. The same mechanism also fits HTTP/3 CONNECT tunnels, intermediary failures after response commitment, malformed decoded HTTP messages, and requests rejected before application processing. Discussion Venues Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP/3 uses QUIC streams to carry requests and responses. Several HTTP/3 errors are signaled by abruptly terminating a stream with an error code, but a QUIC stream reset does not ensure delivery of data sent before the reset. This matters when the sender has a useful bounded prefix, but the correct HTTP/3 outcome is still a stream error. Examples include a proxy that has received response bytes before an upstream failure, or a server that has decoded a malformed request and wants to send a short diagnostic response before using H3_MESSAGE_ERROR. RESET_STREAM_AT adds a Reliable Size to the reset, so stream data up to that point is delivered reliably while the stream still terminates abruptly. WebTransport over HTTP/3 already uses this extension to ensure delivery of the prefix that associates a WebTransport stream with its session. The following sections describe HTTP/3 cases where reliable prefix delivery is useful while retaining the existing stream-error signal.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Use Cases

CONNECT Tunnels The relay use case described in directly applies to HTTP/3 CONNECT. HTTP/3 CONNECT carries tunnel data in DATA frames after a successful CONNECT response. says that TCP connection errors, including TCP reset, are signaled as stream errors of type H3_CONNECT_ERROR. A proxy might receive bytes from the upstream TCP connection and then observe an upstream reset. With a plain stream reset, DATA frames containing those upstream bytes might be lost and will not be retransmitted. Using RESET_STREAM_AT allows the proxy to signal H3_CONNECT_ERROR while still delivering the upstream bytes that it has committed to forwarding. For this use case, the Reliable Size SHOULD be the end of the last committed DATA frame carrying tunnel bytes from the upstream connection.

Intermediaries After Response Commitment An intermediary can translate an upstream failure into a new HTTP response only before it sends response headers downstream. After that, it cannot replace the response with a new status code. If the intermediary later detects an upstream stream error, a malformed upstream response, or another stream-local failure, RESET_STREAM_AT allows it to terminate the stream with an appropriate HTTP/3 error code while making reliable only the response portion it can safely identify. That portion always includes the committed response HEADERS frame, and can include later response data when the intermediary understands enough of the application protocol to choose a useful boundary. The Reliable Size SHOULD therefore be the end of the response HEADERS frame, or the end of a later complete HTTP/3 frame forwarded downstream. This is mainly useful for diagnostics, logging, and clients that can consume a partial streaming response before an error.

Malformed Decoded HTTP Messages This use case applies after an HTTP/3 HEADERS frame has been parsed and QPACK decompression has succeeded. It does not apply to invalid HTTP/3 frame syntax, invalid frame ordering, or QPACK decompression failure. Examples of malformed HTTP messages under include invalid pseudo-header fields and uppercase field names. A detected malformed message is treated as a stream error of type H3_MESSAGE_ERROR. RESET_STREAM_AT allows a diagnostic HTTP response to be delivered while preserving the H3_MESSAGE_ERROR signal. The Reliable Size SHOULD be the end of the diagnostic response HEADERS frame, or the end of a later complete DATA frame carrying a short diagnostic response body. The additional information can be valuable when debugging faulty or non-conforming clients.

Requests Rejected Before Application Processing defines H3_REQUEST_REJECTED for requests that a server rejects without performing application processing. A client can treat such a request as though it had never been sent. H3_REQUEST_REJECTED is not used after partial or full application processing. A server might want to preserve this retry signal while also providing a small diagnostic response. For example, a server that is draining, overloaded, or unable to route a request might send a 503 or 429 response with retry information, then terminate the stream with H3_REQUEST_REJECTED. With RESET_STREAM_AT, the Reliable Size SHOULD be the end of the diagnostic response HEADERS frame, or the end of a later complete DATA frame carrying a short diagnostic response body. This is mainly useful for HTTP/3-aware clients and debugging tools. A generic HTTP client API might not expose both the HTTP response and the stream error.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References Fastly QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection.

Acknowledgments TODO acknowledge.