| Internet-Draft | Reliable QUIC Stream Resets in HTTP/3 | June 2026 |
| Seemann | Expires 31 December 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/.¶
Source for this draft and an issue tracker can be found at https://github.com/marten-seemann/draft-seemann-httpbis-reset-stream-at.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
HTTP/3 [HTTP3] 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 [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 [WEBTRANS-HTTP3] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The relay use case described in [RESET-STREAM-AT] directly applies to HTTP/3 CONNECT. HTTP/3 CONNECT carries tunnel data in DATA frames after a successful CONNECT response. [HTTP3] 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.¶
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.¶
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 [HTTP3] 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.¶
[HTTP3] 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.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶