Google

rch@google.com

TODO HTTP Internet-Draft The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered. This document describes the mechanism for HTTP/3. 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 defines an extension to HTTP/2 which is also useful in HTTP/3. This extension makes use of an HTTP/2 setting. describes the required updates for HTTP/2 settings to be used with HTTP/3.

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.

Websockets Upgrade over HTTP/3 defines a mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection. It defines an Extended CONNECT method which specifies a new ":protocol" pseudo header field and new semantics for the ":path" and ":authority" pseudo header fields. It also defines a new HTTP/2 SETTING sent by a server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection closure of . Orderly TCP-level closures are represented as a FIN bit on the stream (). RST exceptions are represented with an stream error () of type H3_REQUEST_CANCELLED () The semantics of the headers and SETTING are identical to those in HTTP/2 as defined . requires thatt HTTP/3 settings be registered separately for HTTP/3. The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Security Considerations This document introduces no new security considerations beyond those discussed in .

IANA Considerations This document registers a new setting in the "HTTP/3 Settings" registry ().

Setting Name	Value	Specification	Default
SETTINGS_ENABLE_CONNECT_PROTOCOL	0x08	This document	0

Normative References Akamai 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. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. 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. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK] The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations.

Acknowledgments TODO acknowledge.