RFC 9220

Bootstrapping WebSockets with HTTP/3

📅 published June 2022, from ietf

RFC 9220: Bootstrapping WebSockets with HTTP/3 🦋

okay so the title block is giving everything we need 💅

  • Author: Ryan Hamilton, Google (just one author, iconic solo energy ✨)
  • Category: Standards Track
  • Date: June 2022
  • Stream: Internet Engineering Task Force (IETF), with ISSN 2070-1721
  • Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates

Abstract 🌸

okay this is the tea. WebSockets can run over a single stream of an HTTP/2 connection, and that same trick works just as well for HTTP/3. The version-specific details just needed to be written down, and that's what this doc does 🫶

Status of This Memo 📜

this is an Internet Standards Track document 🎀

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841.

for info on the current status of this doc, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9220 💜

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read them, because they spell out your rights and restrictions for this document. any Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🔥

Table of Contents 🧚

  • 1. Introduction
  • 2. Conventions and Definitions
  • 3. WebSockets Upgrade over HTTP/3
  • 4. Security Considerations
  • 5. IANA Considerations
  • 6. Normative References
  • Acknowledgments
  • Author's Address

1. Introduction 🦋

okay so "Bootstrapping WebSockets with HTTP/2" [RFC8441] defines an extension to HTTP/2 [HTTP/2] that's also super useful in HTTP/3 [HTTP/3]. it works by using an HTTP/2 setting. Appendix A.3 of [HTTP/3] gives some guidance on what changes (if any) make sense when you port settings from HTTP/2 over to HTTP/3 🌈

2. 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 get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here ✨

3. WebSockets Upgrade over HTTP/3 💖

so [RFC8441] sets up a way to run the WebSocket Protocol [RFC6455] over a single stream of an HTTP/2 connection. it defines an Extended CONNECT method that adds 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 that a server sends so the client is allowed to use Extended CONNECT 🎀

the semantics of those pseudo-header fields and that setting are identical to what [RFC8441] defines for HTTP/2. Appendix A.3 of [HTTP/3] requires that HTTP/3 settings get registered separately for HTTP/3, so the SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), same as HTTP/2 🧚

if a server advertises support for Extended CONNECT but gets an Extended CONNECT request with a :protocol value that's unknown or not supported, the server SHOULD respond to that request with a 501 (Not Implemented) status code (Section 15.6.2 of [HTTP]). the server MAY also send more info through a "problem details" response [RFC7807] 💅

and then the closing part, which is so cute: the HTTP/3 stream closure is analogous to the TCP connection closure in [RFC6455]. orderly TCP-level closures show up as a FIN bit on the stream (Section 4.4 of [HTTP/3]). RST exceptions are shown as a stream error (Section 8 of [HTTP/3]) of type H3_REQUEST_CANCELLED (Section 8.1 of [HTTP/3]) 🦋

4. Security Considerations 💀

okay bestie, this part is serious. this document introduces no new security considerations beyond the ones discussed in [RFC8441]. go read those 🙈

5. IANA Considerations 🍓

this doc registers a new setting in the "HTTP/3 Settings" registry (Section 11.2.2 of [HTTP/3]). here's the entry, verbatim:

Value:  0x08
Setting Name:  SETTINGS_ENABLE_CONNECT_PROTOCOL
Default:  0
Status:  permanent
Specification:  This document
Change Controller:  IETF
Contact:  HTTP Working Group (ietf-http-wg@w3.org)

6. Normative References 📚

[HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
           DOI 10.17487/RFC9113, June 2022,
           <https://www.rfc-editor.org/info/rfc9113>.

[HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
           June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
           RFC 6455, DOI 10.17487/RFC6455, December 2011,
           <https://www.rfc-editor.org/info/rfc6455>.

[RFC7807]  Nottingham, M. and E. Wilde, "Problem Details for HTTP
           APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
           <https://www.rfc-editor.org/info/rfc7807>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8441]  McManus, P., "Bootstrapping WebSockets with HTTP/2",
           RFC 8441, DOI 10.17487/RFC8441, September 2018,
           <https://www.rfc-editor.org/info/rfc8441>.

Acknowledgments 🫶

this doc had reviews and input from lots of contributors in the IETF HTTP and QUIC Working Groups 🌸 with substantive input from David Schinazi, Martin Thomson, Lucas Pardue, Mike Bishop, Dragana Damjanovic, Mark Nottingham, and Julian Reschke. iconic team 👑

Author's Address 🧚

Ryan Hamilton
Google
Email: rch@google.com
📦 where this page comes from