<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!--  draft submitted in xml v3 -->
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.25 (Ruby 3.0.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" ipr="trust200902" docName="draft-ietf-httpbis-h3-websockets-04" number="9220" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.1 -->
  <front>
    <title>Bootstrapping WebSockets with HTTP/3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-h3-websockets-04"/> name="RFC" value="9220"/>
    <author initials="R." surname="Hamilton" fullname="Ryan Hamilton">
      <organization>Google</organization>
      <address>
        <email>rch@google.com</email>
      </address>
    </author>
    <date year="2022" month="February" day="08"/> month="June"/>
    <area>ART</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>extended connect</keyword>
    <keyword>42</keyword>
    <abstract>
      <t>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
HTTP-version-specific details need to be specified. This document describes
how the mechanism is adapted for HTTP/3.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-h3-websockets/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>),
        which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
        Working Group information can be found at <eref target="https://httpwg.org/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/h3-websockets"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>"Bootstrapping WebSockets with HTTP/2"
      <t>"<xref target="RFC8441" format="title"/>" <xref target="RFC8441"/> target="RFC8441" format="default"/> defines an extension
to HTTP/2 <xref target="HTTP2"/> which that is also useful in HTTP/3 <xref target="HTTP3"/>.
This extension makes use of an HTTP/2 setting.  <xref section="A.3" sectionFormat="of" target="HTTP3"/>
gives some guidance on what changes (if any) are appropriate when porting
settings from HTTP/2 to HTTP/3.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="websockets-upgrade-over-http3">
      <name>Websockets
      <name>WebSockets Upgrade over HTTP/3</name>
      <t><xref target="RFC8441"/> defines a mechanism for running the WebSocket Protocol
<xref target="RFC6455"/> over a single stream of an HTTP/2 connection. It defines
an Extended CONNECT method which that 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.</t>
      <t>The semantics of the pseudo-header fields and setting are identical to those
in HTTP/2 as defined in <xref target="RFC8441"/>. <xref section="A.3" sectionFormat="of" target="HTTP3"/> requires that
HTTP/3 settings be registered separately for HTTP/3. The
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.</t>
      <t>If a server advertises support for Extended CONNECT but receives an
Extended CONNECT request with a ":protocol" value that is unknown or is
not supported, the server <bcp14>SHOULD</bcp14> respond to the request with a 501 (Not
Implemented) status code (<xref section="15.6.2" sectionFormat="of" target="HTTP"/>). A server <bcp14>MAY</bcp14>
provide more information via a Problem Details "problem details" response <xref target="RFC7807"/>.</t>
      <t>The HTTP/3 stream closure is also analogous to the TCP connection
closure of <xref target="RFC6455"/>. Orderly TCP-level closures are represented as
a FIN bit on the stream (<xref section="4.2" section="4.4" sectionFormat="of" target="HTTP3"/>). RST exceptions are
represented with a stream error (<xref section="8" sectionFormat="of" target="HTTP3"/>) of type
H3_REQUEST_CANCELLED (<xref section="8.1" sectionFormat="of" target="HTTP3"/>).</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document introduces no new security considerations beyond those
discussed in <xref target="RFC8441"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document registers a new setting in the "HTTP/3 Settings"
registry (<xref section="11.2.2" sectionFormat="of" target="HTTP3"/>).</t>
      <dl>
      <dl spacing="compact">
        <dt>
Value:  </dt>
        <dd>
          <t>0x08</t>
        </dd>
        <dt>
Setting Name:  </dt>
        <dd>
          <t>SETTINGS_ENABLE_CONNECT_PROTOCOL</t>
        </dd>
        <dt>
Default:  </dt>
        <dd>
          <t>0</t>
        </dd>
        <dt>
Status:  </dt>
        <dd>
          <t>permanent</t>
        </dd>
        <dt>
Specification:  </dt>
        <dd>
          <t>This Document</t>
        </dd>
        <dt>
Date:  </dt>
        <dd>
          <t>[ date of publication ]</t> document</t>
        </dd>
        <dt>
Change Controller:  </dt>
        <dd>
          <t>IETF</t>
        </dd>
        <dt>
Contact:  </dt>
        <dd>
          <t>HTTP Working Group (ietf-http-wg@w3.org)</t>
        </dd>
        <dt>
Notes:  </dt>
        <dd>
          <!-- -->
  </dd>
      </dl>
    </section>
  </middle>
  <back>
    <displayreference target="HTTP3" to="HTTP/3"/>
    <displayreference target="HTTP2" to="HTTP/2"/>
    <references>
      <name>Normative References</name>
      <reference anchor="HTTP3">
        <front>
          <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
          <author fullname="Mike Bishop" initials="M." surname="Bishop">
            <organization>Akamai</organization>
          </author>
          <date day="2" month="February" year="2021"/>
          <abstract>
            <t>   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.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
      </reference>
      <reference anchor="HTTP2">
        <front>
          <title>HTTP/2</title>
          <author fullname="Martin Thomson" initials="M." surname="Thomson">
            <organization>Mozilla</organization>
          </author>
          <author fullname="Cory Benfield" initials="C." surname="Benfield">
            <organization>Apple Inc.</organization>
          </author>
          <date day="24" month="January" year="2022"/>
          <abstract>
            <t>   This specification describes an optimized expression of the semantics
   of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
   version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network
   resources and a reduced latency by introducing field compression and
   allowing multiple concurrent exchanges on the same connection.

   This document obsoletes RFC 7540 and RFC 8740.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-07"/>
      </reference>
      <reference anchor="HTTP">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="Roy T. Fielding" initials="R. T." surname="Fielding">
            <organization>Adobe</organization>
          </author>
          <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
            <organization>Fastly</organization>
          </author>
          <author fullname="Julian Reschke" initials="J." surname="Reschke">
            <organization>greenbytes GmbH</organization>
          </author>
          <date day="12" month="September" year="2021"/>
          <abstract>
            <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document describes the overall architecture of HTTP,
   establishes common terminology, and defines aspects of the protocol
   that are shared by all versions.  In this definition are core
   protocol elements, extensibility mechanisms, and the "http" and
   "https" Uniform Resource Identifier (URI) schemes.

   This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
   7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
   of RFC 7230.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/>
      </reference>
      <reference anchor="RFC8441">
        <front>
          <title>Bootstrapping WebSockets with HTTP/2</title>
          <author fullname="P. McManus" initials="P." surname="McManus">
            <organization/>
          </author>
          <date month="September" year="2018"/>
          <abstract>
            <t>This document defines a mechanism for running the WebSocket Protocol
<!-- [HTTP/3] draft-ietf-quic-http (RFC 6455) over a single stream of an HTTP/2 connection.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8441"/>
        <seriesInfo name="DOI" value="10.17487/RFC8441"/>
      </reference> 9114) -->
      <reference anchor="RFC2119"> anchor='HTTP3' target="https://www.rfc-editor.org/info/rfc9114">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <title>HTTP/3</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/> initials='M' surname='Bishop' fullname='Mike Bishop' role="editor">
            <organization />
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>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.</t>
          </abstract> year='2022' month='June' />
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/> value="9114"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/> value="10.17487/RFC9114"/>
      </reference>
<!-- [HTTP/2] draft-ietf-httpbis-http2bis (RFC 9113) -->
      <reference anchor="RFC8174"> anchor='HTTP2' target="https://www.rfc-editor.org/info/rfc9113">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <title>HTTP/2</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization/> initials='M' surname='Thomson' fullname='Martin Thomson' role="editor">
            <organization />
          </author>
          <author initials='C' surname='Benfield' fullname='Cory Benfield' role="editor">
            <organization />
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>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.</t>
          </abstract> year='2022' month='June' />
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/> value="9113"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/> value="10.17487/RFC9113"/>
      </reference>
<!-- [HTTP] draft-ietf-httpbis-semantics (RFC 9110) -->
      <reference anchor="RFC6455"> anchor='HTTP' target="https://www.rfc-editor.org/info/rfc9110">
        <front>
          <title>The WebSocket Protocol</title>
          <author fullname="I. Fette" initials="I." surname="Fette">
            <organization/>
          </author>
          <title>HTTP Semantics</title>
          <author fullname="A. Melnikov" initials="A." surname="Melnikov">
            <organization/> initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
            <organization />
          </author>
          <author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor">
            <organization />
          </author>
          <author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
            <organization />
          </author>
          <date month="December" year="2011"/>
          <abstract>
            <t>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 &lt;iframe&gt;s and long polling).  [STANDARDS-TRACK]</t>
          </abstract> year='2022' month='June' />
        </front>
        <seriesInfo name="RFC" value="6455"/>
        <seriesInfo name="DOI" value="10.17487/RFC6455"/>
      </reference>
      <reference anchor="RFC7807">
        <front>
          <title>Problem Details for HTTP APIs</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham">
            <organization/>
          </author>
          <author fullname="E. Wilde" initials="E." surname="Wilde">
            <organization/>
          </author>
          <date month="March" year="2016"/>
          <abstract>
            <t>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
          </abstract>
        </front> name="STD" value="97"/>
        <seriesInfo name="RFC" value="7807"/> value="9110"/>
        <seriesInfo name="DOI" value="10.17487/RFC7807"/> value="10.17487/RFC9110"/>
      </reference>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8441.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7807.xml"/>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document had reviews and input from many 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, <contact fullname="David Schinazi"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Lucas Pardue"/>, <contact fullname="Mike Bishop"/>, <contact fullname="Dragana Damjanovic"/>, <contact fullname="Mark Nottingham"/>, and
Julian Reschke.</t> <contact fullname="Julian Reschke"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJaXAmIAA5VX4XIaORL+r6fQcn/iKw824Gwcam9rCSaxr2zwGXKprdSW
S8wI0DEjTSSNCevyu+yz7JPd15oZYGKn9u6PGUvdre6vuz+1oihiXvlU9nnr
nTHeeSvyXOkl/yTnUxOvpXd8o/yKX85mtye9FktMrEUG+cSKhY+U9Ito5X0+
Vy5a9aKNnLtSLTo9Y7Hwcmnsts+dTxhTue1zbwvnu6enb0+7TFgp+nxwN2Mb
Y9dLa4q8H05ia7nFUtLnV9pLq6WPLug89iB1IfuM80Nhzv02h0ufYIR8/0B7
WF0ZcpS8c/2TE/rdLNvGLk+wlwmV9vnO/Wiz/GXTo03sCRuv9nqpct61y82T
AbbUg3Qnt8U8VfHJoQEya2Vu9qpLIFfM27HJqtPDTyS/eqmdMtqdpGIuU3fS
QI6VapFyrpBRkIDJhoTzQif3IjUaAW4lFjJh/f2Xwnjp+lwblqs+/+xNfMyd
sd7KhcPXNqOP3xgThV8ZCxwj+Mx5mdG7rdD8UmQq9UaHdUQstPpdePja5x+M
WaYybMgSPoDxyzKsUoyMaWMzCD+EDFFqekhgdNE+qJUvhYpLwHpnlVD3mdCu
oPDbpY/TN5Xsd0UdXNJexS7qvEWl6cXeFcaiKOJiTsUde8ZmK8kzGa8Qmss4
BLkttKbC8djZFT6/tQYAmpSbB2m54A4iqUQpo2ozZhac4KK26PLYaC1jgokr
x+WXQqTplqOVUCNiDiVvqg465vPCh4NC6cIyFULkchmrhYp5Ij2gdVxLmZDW
HAeWezJp89kK5tGCRSa1h6yLrZoj/SuzCTb3YUFOJCL3sEIRloe3SygylSRI
JPsbdZc1SRE8Z+x/oYBuiz8+/nD3fnh+dtZ5eoIPC6WlIyx2Zc3qaLuQDRmG
4Gal4lVwK3WGF04uipSrCsFeJdh7emqzEOTOGDp1DftQ4A3InfQeXrY5VAd5
LnWivvJBu0dSlSk0EloVDZBJvixUInQMIxquCM8JqCV2Xymyuj1C10vKmDW5
VeAtSEnNczQPTmHVaY4vrMlqF3ZJBa4Ac2g06ImgJDgSfkHQqPB/WXQgNU6s
5njr5uN01jouf/l4Er7vRv/6eHU3uqDv6eXg+nr3wSqJ6eXk4/XF/muvOZzc
3IzGF6UyVnljibVuBr9ih7xqTW5nV5Px4LpF6PtGQREEZc0pot3cSqof4Vhd
aQnpvBve/vlH56yqg26n8xbprYqi8+Ys5Frq8jSj0Qflv6jPLQPAUliygg7h
sciVRz1AFmlCEWu+klYCzr9/JmR+6/Of5nHeOfu5WqCAG4s1Zo3FgNnzlWfK
JYgvLL1wzA7Nxvo3SDf9Hfza+L/G/WCRqubTjtX5x3xpRSJLvikri7GXu+3/
IrDKxo9nr1/Dxktsxr/DZm1+5etDGQRG1JUJymA4GY9HwxncwEWSVM1dExX5
p+WGt/p55UGL5U4WiYlWEgFaDqE0CQVCcjvuDrFQDNAUftUqC7Zf3lbKb180
44KTgVX28JDZJlHgFxU+31Lo0hIG3jAUYcWccapo3wdq4s8CbZcdvPcUgJHa
S/4Er+tTqaVUQrQQi5TMIxQnmdqBjcov3U4axNr+Pq1hyMAtahGnB5GxikB3
DIXutXKJoQWdRH7kwoLO0IYH9wAuEsmmo9nsavxhej8aD95dj+6rUO9v7yaz
yXByzR9EWkii7NOvp+f8VYLsZgji/Cj06y4EYHO12MMqEvz1yhHzFjkRaDj5
WenQPWhlLANHC82eCVCY0vny8hGH1VR5RuGTe4Vea+IOnKIchhBfHyyTQDu1
Z1VzA7nc6KRMhvz2mNenHf5qbDy7yvJUEi3K5AhtInzh0Bloz1ePj9Pqsu+8
bv/Y7ta5eXo6avNBfRr6n8HjB2SfZ4bKoB5KoPigBM5Cg2I4yHBTlJd+6Rnq
r6yEN+enb+hCDKVXp7ns1zg1rrByd58KjWFwaeBiFdVseHvQx6yWh6eHZNDm
E4vCRXFAPkrlg0xr0y6ULuZZfAYQ6B4Q/P3VmM+Vp2s0IFu6cwDJ2R6PXgDk
DrQtv8Yyr25GK9mh1Qr2ypC0Flk8MHd+aCx0HUZ9dtm7J+YfTWf3w8F4OLq+
Hl00tNqdhhNEtNgriETonnZIihW7q/nwDlTVSAQAtKnoqVKMG4potG0oo9DQ
iXJx4Vx5QzYaOcxZg/HgL86te7Zmr5pAVAl0q8r/tGrzFisV7LZRj5129xv8
Gfs3NUuf9UMbM1ZZ4GMa+rH6VzTAGAYZUaQ+mIB+aAX6J5coZw3nsVjNr+VT
AXshuIsqOJgABdHyZ57QbAUH8/CAKrsBL5JhGMcII8CfptKS9NVo9h5bWMPg
TgsUVfOZh/nt+RvuiLFxeAlB5acfMPFG0c/l6DsX8ZoSMoiJMlKZLMk/xx77
usjmxJj/aC3QUbL19G2CViJBkh6U3JQMr3QOBgvzIFAI1eExIxXeWFdnjQIo
B33SwKgybHqPySfUvyvm9KSj98qh3QsB9uBTPDm1+F0d8xtB0yj8MpkzGKmu
ixhEfCtsUkjsqrXk7xTmqPyY47mMt5uAiew/QoOF4qC+5gCG0r8SWZjQ2D+L
VOFmv8OEt1pj9PovamA0tRMQAAA=

-->
</rfc>