Bootstrapping WebSockets with HTTP/3
Extracted elements (9)
The mechanism for running WebSockets over HTTP/2 (RFC 8441) is directly applicable to HTTP/3 because both use stream-based framing with similar semantics; only the HTTP-version-specific registration details needed to be specified in this document.
Appendix A.3 of HTTP/3 (RFC 9114) requires that HTTP/3 settings be registered separately for HTTP/3, even when porting settings from HTTP/2. This document satisfies that requirement for SETTINGS_ENABLE_CONNECT_PROTOCOL.
A server MAY provide more information via a 'problem details' response (RFC 7807) when rejecting an unsupported Extended CONNECT ':protocol' value.
If a server advertises support for Extended CONNECT but receives an Extended CONNECT request with a ':protocol' value that is unknown or not supported, the server SHOULD respond with a 501 (Not Implemented) status code.
HTTP/3 stream closure maps to WebSocket connection closure analogously to TCP: orderly closure is represented as a FIN bit on the stream (Section 4.4 of HTTP/3), and RST exceptions are represented with a stream error of type H3_REQUEST_CANCELLED (Section 8.1 of HTTP/3).
The Extended CONNECT method for HTTP/3 uses the same ':protocol', ':path', and ':authority' pseudo-header field semantics as defined in RFC 8441 for HTTP/2, with no changes to their meaning.
The SETTINGS_ENABLE_CONNECT_PROTOCOL setting is registered for HTTP/3 with value 0x08 (decimal 8), identical to its HTTP/2 value. This setting is sent by a server to allow the client to use Extended CONNECT.
This document registers SETTINGS_ENABLE_CONNECT_PROTOCOL (value 0x08, default 0, status permanent) in the IANA 'HTTP/3 Settings' registry (Section 11.2.2 of RFC 9114).
This document introduces no new security considerations beyond those discussed in RFC 8441 (Bootstrapping WebSockets with HTTP/2).