]> The University of Tokyo/WIDE Project

Japan momoka.my6@gmail.com

Applications and Real-Time HTTP WebSockets This document proposes a new HTTP settings parameter, SETTINGS_ENABLE_WEBSOCKETS. This parameter indicates whether the server supports bootstrapping WebSockets over the established connection. 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 The mechanisms for running the WebSocket protocol over a single stream of an HTTP/2 and HTTP/3 connection is defined in and . The extended CONNECT mechanism is used for bootstrapping WebSockets from HTTP/2 and HTTP/3. Support for the extended CONNECT mechanism is advertised using HTTP/2 and HTTP/3 settings parameter SETTINGS_ENABLE_CONNECT_PROTOCOL. However, the support of extended CONNECT does not necessarily indicate support for WebSockets over that HTTP connection. Other protocols such as also use extended CONNECT and send SETTINGS_ENABLE_CONNECT_PROTOCOL settings parameters as well. Suppose the server supports extended CONNECT but not bootstrapping WebSockets over that HTTP connection. In this case, the client sending a WebSocket handshake request will result in a response of 501 (Not Implemented) status code (Section 15.6.2 of ), and the client would need to fall back to trying the WebSocket handshake over HTTP/1. This is why a SETTINGS_ENABLE_WEBSOCKETS settings parameter is needed.

SETTINGS_ENABLE_WEBSOCKETS settigs parameter for H2 and H3 This document adds a new SETTINGS parameter to those defined by Section 11.2.2 and Section 11.3. The new parameter name is SETTINGS_ENABLE_WEBSOCKETS. The value of the parameter MUST be 0 or 1, with 0 being the default. A sender MUST NOT send a SETTINGS_ENABLE_WEBSOCKETS parameter with the value of 0 after previously sending a value of 1. If the server supports bootstrapping WebSockets over the HTTP connection, it SHOULD include the SETTINGS_ENABLE_WEBSOCKETS parameter in the SETTINGS frame with a value of 1. If the server does not support bootstrapping WebSockets over the HTTP connection it SHOULD send the parameter with a value of 0. A client MUST not send this setting parameter. Receipt of this parameter by a server does not have any impact. The SETTINGS_ENABLE_WEBSOCKETS parameter would allow the client to determine in advance whether the server supports WebSockets over the connection for HTTP/2 or HTTP/3. This allows the client to avoid sending unnecessary WebSocket handshake requests on HTTP connections that do not support WebSockets. This mechanism will improve compatibility with other extended CONNECT-based protocols. For compatibility with past implementations which do not use this parameter, clients MAY initiate a WebSocket request without the receipt of this parameter.

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

IANA Considerations

HTTP3 This document registers a new entry in the "HTTP/3 Settings" registry (Section 11.2.2 of ). Value: TBD Setting Name: SETTINGS_ENABLE_WEBSOCKETS Default: 0 Status: permanent Specification: This document Change Controller: IETF Contact: HTTP Working Group (ietf-http-wg@w3.org)

HTTP2 This document registers a new entry in the "HTTP/2 Settings" registry (Section 11.1 of ). Code: TBD Name: SETTINGS_ENABLE_ENABLE_WEBSOCKETS Default: 0 Status: permanent Specification: This document Change Controller: IETF Contact: HTTP Working Group (ietf-http-wg@w3.org)

References Normative References Adobe Fastly greenbytes Mozilla Apple Inc. Akamai 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] This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. 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. Informative References Google The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional.

Acknowledgments TODO acknowledge people. Thank you for reading this draft. :)