]> Zscaler

yrosomakho@zscaler.com

Google LLC

dschinazi.ietf@gmail.com

Web and Internet Transport HTTP http data unbound This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a request or response stream, it indicates that all subsequent octets on that stream are interpreted as data. This applies both to message body data and to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived or indeterminate-length payloads. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction transmits message content on client-initiated bidirectional QUIC streams. On these streams, the request and response messages are carried using a sequence of HTTP/3 frames. The DATA frame is used to encapsulate octets of a message body, or the opaque data associated with CONNECT and its extensions. When the size of the body is unknown in advance, or when data is generated incrementally such as media streaming, , , or other tunneled protocols using CONNECT and its extensions, senders typically generate many DATA frames. Although DATA frames are lightweight, each adds framing overhead and requires the sender to manage frame boundaries. For long-lived or high-volume streams, this overhead is unnecessary because the end of the QUIC stream already provides a natural message boundary. This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that endpoints use to negotiate support. Once an UNBOUND_DATA frame is sent on a request or response stream, all subsequent octets on that stream are interpreted as data. This mechanism eliminates the need to encapsulate each portion of the body in separate DATA frames. The goals of UNBOUND_DATA are:

• Reduce framing overhead for large or indeterminate-length message bodies.
• Simplify sender and receiver state machines by eliminating repeated DATA frame headers.
• Enable efficient transport of long-lived data flows such as streaming APIs, media delivery, or tunneled protocols.

The use of UNBOUND_DATA does not alter HTTP semantics, flow control, or prioritization; it is strictly a framing optimization.

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.

Capability Negotiation Endpoints indicate support for unbound data transmission by sending the SETTINGS_ENABLE_UNBOUND_DATA (0x282cf6bb) setting with a value of 1. The valid values of the SETTINGS_ENABLE_UNBOUND_DATA setting are 0 and 1. If the SETTINGS_ENABLE_UNBOUND_DATA setting is received with a different value, the receiver MUST treat it as a connection error of type H3_SETTINGS_ERROR. A value of 1 indicates that the sender of the SETTINGS frame is willing to receive UNBOUND_DATA frames. Endpoints MUST NOT send an UNBOUND_DATA frame to a peer that has not advertised SETTINGS_ENABLE_UNBOUND_DATA with a value of 1. Endpoints that receive an UNBOUND_DATA frame without having advertised support MUST treat it as a connection error of type H3_FRAME_UNEXPECTED. The SETTINGS_ENABLE_UNBOUND_DATA parameter is directional: each endpoint independently advertises whether it accepts receiving UNBOUND_DATA. An endpoint that has not indicated support cannot be assumed to understand or correctly process the frame.

UNBOUND_DATA Frame The UNBOUND_DATA frame (type=0x2a937388) is used on request or response streams to indicate that all subsequent octets on the stream are interpreted as data. This data can represent an HTTP message body or the data stream as defined in .

Frame Layout

HTTP/3 UNBOUND_DATA Frame

The UNBOUND_DATA frame has no payload. The Length field of the frame MUST be zero. If a nonzero length is received, the endpoint MUST treat this as a connection error of type H3_FRAME_ERROR. The UNBOUND_DATA frame is only valid on request or response streams. It is invalid on control streams, QPACK encoder/decoder streams, or push streams. If an endpoint receives an UNBOUND_DATA frame on a stream that isn't a client-initiated bidirectional stream, it MUST treat it as a connection error of type H3_FRAME_UNEXPECTED. Similar to DATA frames, endpoints MUST sent a HEADERS frame before sending an UNBOUND_DATA frame on a given stream. Receipt of an UNBOUND_DATA frame on a stream that hasn't received a HEADERS frame MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.

Semantics Upon receiving an UNBOUND_DATA frame on a request or response stream, the receiver enters unbound mode for that stream. In unbound mode:

• All remaining octets on the stream, up to the QUIC FIN, are interpreted as data.
• No further HTTP/3 frames (including DATA, HEADERS, or any extension frames) can be received on the stream.
• The end of the data is indicated by the QUIC FIN on the stream.
• If a Content-Length header was included, the recipient needs to ensure that the combined length of all received data (in both DATA and UNBOUND_DATA frames) matches the content length from the header.

Stream State Transitions The use of the UNBOUND_DATA frame modifies the sequence of frames exchanged on request and response streams. In normal operation, a request or response body is carried as a sequence of one or more DATA frames, followed optionally by a HEADERS frame containing trailers:

Regular HTTP/3 Frame sequence on bi-directional stream +------------------------+ | HEADERS (headers) | +------------------------+ | [ DATA ... ] | +------------------------+ | [ HEADERS (trailers) ] | QUIC FIN ----> +------------------------+ ]]>

When UNBOUND_DATA is used, the sender signals that all subsequent octets on the stream are data. Regular DATA frames MAY be sent on a stream prior to the UNBOUND_DATA. After the UNBOUND_DATA frame, the sender cannot send any further HTTP/3 frames on the stream. The end of the body is signaled by the QUIC stream FIN:

HTTP/3 Frame sequence with UNBOUND_DATA +------------------------+ | HEADERS (headers) | +------------------------+ | [ DATA ... ] | +------------------------+ | UNBOUND_DATA | +------------------------+ | Raw octets (data only) | QUIC FIN ----> +------------------------+ ]]>

Since the recipient of an UNBOUND_DATA will no longer parse frame types on the stream after its receipt, it is not possible to send other frames after the UNBOUND_DATA. If that is required, for example if the sender wishes to send trailers, then the UNBOUND_DATA frame cannot be used.

Security Considerations The introduction of UNBOUND_DATA does not alter the security properties of HTTP/3 or QUIC. It only changes how message bodies or tunneled octets are framed on request and response streams.

IANA Considerations

HTTP/3 Setting This specification registers the following entry in the "HTTP/3 Settings" registry defined in :

• Code: 0x282cf6bb
• Setting Name: SETTINGS_ENABLE_UNBOUND_DATA
• Default: 0
• Status: provisional (permanent if this document is approved)
• Reference: This document
• Change Controller: Yaroslav Rosomakho (IETF if this document is approved)
• Contact: yrosomakho@zscaler.com (HTTP_WG; HTTP working group; ietf-http-wg@w3.org if this document is approved)
• Notes: None

HTTP/3 Frame Type This specification registers the following entry in the "HTTP/3 Frame Types" registry defined in :

• Value: 0x2a937388
• Frame Type: UNBOUND_DATA
• Status: provisional (permanent if this document is approved)
• Reference: This document
• Change Controller: Yaroslav Rosomakho (IETF if this document is approved)
• Contact: yrosomakho@zscaler.com (HTTP_WG; HTTP working group; ietf-http-wg@w3.org if this document is approved)
• Notes: None

References Normative References 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. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. Informative References The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. 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 This specification originated from discussions with Christian Huitema and Alan Frindell, whose ideas and feedback helped shape the approach described in this document. The authors thanks them for their valuable contributions.