]> 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 CONNECT request or response stream, it indicates that all subsequent octets on that stream are interpreted as tunneled bytes. This applies both 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 CONNECT tunnels. 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 the opaque data associated with CONNECT and its extensions. CONNECT and extended CONNECT establish long-lived bidirectional tunnels. These tunnels commonly carry transport protocols (TCP , UDP , IP , Ethernet , , ) that produce arbitrarily fragmented and continuous byte streams. Senders therefore generate large numbers of DATA frames whose boundaries have no semantic meaning. 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. According to , once HTTP/3 CONNECT tunnel is established, the stream carries opaque bytes until the QUIC FIN. CONNECT streams do not carry trailers and no additional HTTP frames are defined after tunnel establishment. Therefore, ceasing frame parsing after UNBOUND_DATA does not change HTTP semantics and only removes framing overhead. 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 CONNECT stream, all subsequent octets on that stream are interpreted as data. This mechanism eliminates the need to encapsulate each portion of the tunnel payload in separate DATA frames. The goals of UNBOUND_DATA are:

• Reduce framing overhead for CONNECT tunnels carrying continuous byte streams.
• Simplify sender and receiver state machines by eliminating repeated DATA frame headers.
• Enable efficient transport of tunneled protocols carried over CONNECT streams.

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 CONNECT streams to indicate that all subsequent octets on the stream are interpreted as data.

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 CONNECT streams. If an endpoint receives an UNBOUND_DATA frame on a stream that is not a CONNECT stream, it MUST treat it as a connection error of type H3_FRAME_UNEXPECTED. Similar to DATA frames, endpoints MUST send 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 CONNECT 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.

Unbound mode is direction-specific: receipt of UNBOUND_DATA only affects the interpretation of octets received in that direction of the stream. Each endpoint can independently send UNBOUND_DATA to indicate unbound mode for its sending direction.

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 CONNECT request or response is carried as a sequence of one or more DATA frames:

Regular HTTP/3 CONNECT frame sequence on bi-directional stream +------------------------+ | HEADERS (headers) | +------------------------+ | [ DATA ... ] | 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 tunnel 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 ----> +------------------------+ ]]>

Security Considerations The introduction of UNBOUND_DATA does not alter the security properties of HTTP/3 or QUIC. It only changes how the CONNECT payload is 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 :

• Value: 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. Informative References Meta Platforms, Inc. TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. Google LLC This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. 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 also thank Lucas Pardue for providing valuable initial feedback.