From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Tue Feb 28 00:13:29 2023 Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36CBC14CF1F for ; Tue, 28 Feb 2023 00:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AD_PREFS=0.25, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUq77MOW6w3P for ; Tue, 28 Feb 2023 00:13:29 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7250DC152F14 for ; Tue, 28 Feb 2023 00:13:02 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pWv6O-002lkf-6I for ietf-http-wg-dist@listhub.w3.org; Tue, 28 Feb 2023 08:12:48 +0000 Resent-Date: Tue, 28 Feb 2023 08:12:48 +0000 Resent-Message-Id: Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pWv6M-002ljh-2L for ietf-http-wg@listhub.w3.org; Tue, 28 Feb 2023 08:12:46 +0000 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pWv6K-00ER7X-IN for ietf-http-wg@w3.org; Tue, 28 Feb 2023 08:12:46 +0000 Received: by mail-ed1-x532.google.com with SMTP id s26so36211551edw.11 for ; Tue, 28 Feb 2023 00:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2U2NlvYpHsYcDpDTU84VQY/NIagyRBtRH91yk+/VmJE=; b=B13G9O1CYET+KfjtMo8uLu7kDDhXO6kPOD1VIpnSlHXBLG8jB20+L3kMfe7stD/z6U zTFmGQjwdJySibhjztsrKUmal4+GafNxueIPRILjyfKxJcHMTWrrgMfWf8RkpkZqzcZR UVKmg7EUU5AkpoeZq7cE9IS3s2baK1p7Kw2XzJN2ZYZdGFIOFkaiUKPbmu/xf9Vh9/pj psb5hmn5pqO/Q2qxiAArgWAsAzaKsVNh9Lt1lkmYfYSD7JLMKSzesVg+E9dZxvNZ6z85 KGTkTgAxfKikr+GN7NZj3RwSlD4Eu3vTqXdVpREJVEAsKhgMxgg+iHcn4eWcuKLDPXC/ j8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2U2NlvYpHsYcDpDTU84VQY/NIagyRBtRH91yk+/VmJE=; b=E1tRSHv6azlGmMlTrWC3Zw8fOZ8+onUfaUU2PC1eUgP88na/uLfc19pbjodWwR/NLO 9khOrNbfnwWeIzvlICBCF5DfuU2h/B3c8lfxp1U6K5QQbwjf9ecWFxBnpVFGsKu/Gc7Y D2ZXrZYIHTEWlGWaB9HZQX5dPqet90urHZWav5UJWPKJJPL6XaAmWLK3I9Ibvaue1tKj BAi90gP5kc8oE2FFAurYxhQDHFEWawh/oKJgv07NOFasL8tUx6Q3VU64R6XNnoPuahCC ZwLgIS4aKUwK2I8UKwTVS7KozfLK78/I35fjhYzgArt35iQZaW4RMx6Nn76gz6qtuzgb rcuw== X-Gm-Message-State: AO0yUKWPmLfxWn8LZZlfFBr0MBVrQE9N1dbAcbntwbCG/f387uskq/KL wquWwQ8Q8Fj055ANq5b9ObGFRHJUunSJfAg85Oo= X-Google-Smtp-Source: AK7set8Pk3XVIN51BWm+QLLh7cfIdXHK1hKwuz3lqIa2QibkieaXUrVNX2QoMYs/TM9CJS31JmobDH02sVecbdVcssE= X-Received: by 2002:a05:6402:2811:b0:4af:70a5:5674 with SMTP id h17-20020a056402281100b004af70a55674mr8588994ede.0.1677571953044; Tue, 28 Feb 2023 00:12:33 -0800 (PST) MIME-Version: 1.0 References: <167308384752.44075.8810233925919235602@ietfa.amsl.com> In-Reply-To: From: Momoka Yamamoto Date: Tue, 28 Feb 2023 16:12:21 +0800 Message-ID: To: Lucas Pardue Cc: Ben Schwartz , ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="00000000000058afc805f5be2895" Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=momoka.my6@gmail.com; helo=mail-ed1-x532.google.com X-W3C-Hub-DKIM-Status: validation passed: (address=momoka.my6@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Hub-Spam-Report: AD_PREFS=0.25, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: mimas.w3.org 1pWv6K-00ER7X-IN c97f4365412b2ffeb5c12118ed3567c5 X-Original-To: ietf-http-wg@w3.org Subject: Re: New Version Notification for draft-momoka-httpbis-settings-enable-websockets-00.txt Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/50785 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --00000000000058afc805f5be2895 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I have submitted a new revision of this draft draft-momoka-httpbis-settings-enable-websockets. The changes include Lucas's suggestion of a section explaining why this would be useful. The SETTINGS_ENABLE_WEBSOCKETS parameter is an explicit signal about the server support for bootstrapping WebSockets on the connection. Where a server declares it does not support WebSockets, clients can avoid sending WebSocket handshake requests that would fail. This saves unnecessary work for both client and server, and potentially reduces delays. For instance, a client that learns an HTTP/2 or HTTP/3 connection does not support WebSockets via the setting, could instead attempt to create a WebSocket using the HTTP/1.1 Upgrade mechanism at the immediate moment it is required. Other protocols also rely on the extended CONNECT extension for bootstrapping. This mechanism provides clients with a stronger signal about whether the WebSocket protocol is supported on a connection. This can help improve compatibility with other extended CONNECT-based protocols by avoiding the client making assumption about the supported protocols. Clients that do not implement this extension will not be able to use its signal. In order to support legacy deployments, clients MAY initiate a WebSocket request when they receive SETTINGS_ENABLE_WEBSOCKETS with a value of 0, or if the parameter is omitted from received settings. Such requests could fail, introducing additional latency, which this extension is intended to help avoid. The proposed parameter will be useful if an active HTTP/2 (or HTTP/3) connection to the server already exists when a document with a wss:/ URL is loaded. The browser can then choose whether to try opening the WebSocket stream over the connection, as the proposed SETTINGS_ENABLE_WEBSOCKETS has likely been received by that point. However, the proposed parameter won't be useful when a browser tries to establish a new connection because the SETTINGS will not be received when a decision to use HTTP/2 or HTTP/1 is made. Best, Momoka A new version of I-D, draft-momoka-httpbis-settings-enable-websockets-01.tx= t > has been successfully submitted by Momoka Yamamoto and posted to the > IETF repository. > > Name: draft-momoka-httpbis-settings-enable-websockets > Revision: 01 > Title: SETTINGS_ENABLE_WEBSOCKETS settings parameter for HTTP/2 > and HTTP/3 > Document date: 2023-02-28 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-webs= ockets-01.txt > Status: > https://datatracker.ietf.org/doc/draft-momoka-httpbis-settings-enable-web= sockets/ > Html: > https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-webs= ockets-01.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-momoka-httpbis-settings-enabl= e-websockets > Diff: > https://author-tools.ietf.org/iddiff?url2=3Ddraft-momoka-httpbis-settings= -enable-websockets-01 > > Abstract: > This document proposes a new HTTP settings parameter, > SETTINGS_ENABLE_WEBSOCKETS. This parameter indicates whether the > server supports bootstrapping WebSockets over the established > connection. > > The IETF Secretariat > On Sat, Jan 21, 2023 at 2:07=E2=80=AFAM Momoka Yamamoto wrote: > Hello, > > Thanks for helping me to understand the motivation for this proposal. Do >>> you believe there are existing origins that >>> 1. Offer SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3 AND >>> 2. Operate WebSocket services AND >>> 3. Don't support WebSocket over HTTP/3 AND >>> 4. Are not willing to implement WebSocket over HTTP/3 >>> ? >>> >>> If so, then I agree we have a problem. If not, I think the best course >>> of action is to assume that the origin's supported "Upgrade >>> Tokens"/":protocol values" are independent of HTTP version, except wher= e >>> the IETF has ruled out support for a particular combination of :protoco= l >>> and HTTP version. >>> >> >> I think this is an excellent way to look at the landscape. >> >> My take is that SETTINGS_ENABLE_CONNECT_PROTOCOL declares that a H2 or H= 3 >> server is willing to consider a request with the :protocol pseudo-header= as >> valid syntax. There's nothing saying what values of :protocol it has it = has >> to support. >> >> To question 4, I'd say that is equally a product question as much a >> technical one. RFC 8441 has been knocking around a while but my feeling = is >> that deployments are light. There could be situations where interop or >> implementation bugs mean WebSockets over HTTP/X behave badly while >> WebSockets over HTTP/Y are fine, meanwhile WebTransport over X and Y als= o >> work fine. In that scenario, temporarily disabling a problem variant unt= il >> it can be investigated and fixed is helpful, because the other variants = can >> continue delivering the feature. So allowing fine tuned control over >> variants, such as via an explicit WebSocket setting, would seem to satis= fy >> the server and stop the client from having to guess. >> > > For Ben's question with the 4 statements, 3 and 4 are very likely to be > yes because there are close to no servers implementing WebSockets over > HTTP/3 at the moment. > So then the question will be, "if a server Operate WebSocket services, > will the server never use extended CONNECT mechanisms such as > WebTransport?" And I think this is an assumption that should not be made. > > It would be nice if a client could know if the existing HTTP/3 connection >>>> supports bootstrapping WebSockets. >>>> >>> >>> In my view, clients are free to assume this when they see a wss:// link >>> to an origin that offers SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3. >>> >> >> Thanks for the earlier link to Chrome's behaviour, it helps to frame the >> discussion. Quoting it for ease >> >> > This would only be used for secure WebSockets requests, and only if >> there is already an HTTP/2 connection where the server has already >> advertised support for WebSockets over HTTP/2 via the HTTP/2 SETTINGS >> parameter defined in the specification. >> >> SETTINGS_ENABLE_CONNECT_PROTOCOL doesn't imply that bootstrapping >> websockets is supported IMO, which would mean this assumption doesn't >> strictly hold true. Content that includes a wss:// parameter could be >> generated without any knowledge of the various caches or edges features = - >> there's typically administrative and business relationships between thes= e >> groups. >> >> Since Chrome only sends WebSocket over HTTP/2 on a warm connection with = a >> SETTING of a particular value, changing that value to be >> SETTINGS_ENABLE_WEBSOCKET instead seems like it aligns well with the >> current flow and wouldn't be too disruptive. >> >> For reference, WebTransport over HTTP/3 has been discussing related >> matters; see >> https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/68. >> My understanding is that the discussion has aligned on advertising all >> "layered settings", that is, advertising SETTINGS_ENABLE_CONNECT_PROTOCO= L >> and SETTINGS_ENABLE_WEBTRANSPORT. Defining SETTINGS_ENABLE_WEBSOCKETS wo= uld >> be consistent with that. >> > > > One thing that was very confusing for me when reading RFC8441 was that > it's about "Bootstrapping WebSockets with HTTP/2" but it defines a genera= l > purpose HTTP/2 Extended CONNECT mechanism and > SETTINGS_ENABLE_CONNECT_PROTOCOL. A new settings frame will minimise thi= s > confusion. > And even if we follow Dragana's draft, SETTINGS_ENABLE_WEBSOCKETS will > still be needed to distinguish between advertising support for :protocol > pseudo-headers and support for WebSockets. > > > Momoka > > --00000000000058afc805f5be2895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I have submitted a new revision of this draft=C2=A0draft-mom= oka-httpbis-settings-enable-websockets.

The changes include=C2=A0Lucas's suggestion of a s= ection explaining why this would be useful.

=C2=A0 =C2=A0The SETTIN= GS_ENABLE_WEBSOCKETS parameter is an explicit signal about
=C2=A0 =C2=A0= the server support for bootstrapping WebSockets on the connection.
=C2= =A0 =C2=A0Where a server declares it does not support WebSockets, clients c= an
=C2=A0 =C2=A0avoid sending WebSocket handshake requests that would fa= il.=C2=A0 This
=C2=A0 =C2=A0saves unnecessary work for both client and s= erver, and potentially
=C2=A0 =C2=A0reduces delays.=C2=A0 For instance, = a client that learns an HTTP/2 or
=C2=A0 =C2=A0HTTP/3 connection does no= t support WebSockets via the setting, could
=C2=A0 =C2=A0instead attempt= to create a WebSocket using the HTTP/1.1 Upgrade
=C2=A0 =C2=A0mechanism= at the immediate moment it is required.

=C2=A0 =C2=A0Other protocol= s also rely on the extended CONNECT extension for
=C2=A0 =C2=A0bootstrap= ping.=C2=A0 This mechanism provides clients with a stronger
=C2=A0 =C2= =A0signal about whether the WebSocket protocol is supported on a
=C2=A0 = =C2=A0connection.=C2=A0 This can help improve compatibility with other exte= nded
=C2=A0 =C2=A0CONNECT-based protocols by avoiding the client making = assumption
=C2=A0 =C2=A0about the supported protocols.

=C2=A0 =C2= =A0Clients that do not implement this extension will not be able to use
= =C2=A0 =C2=A0its signal.=C2=A0 In order to support legacy deployments, clie= nts MAY
=C2=A0 =C2=A0initiate a WebSocket request when they receive
= =C2=A0 =C2=A0SETTINGS_ENABLE_WEBSOCKETS with a value of 0, or if the parame= ter is
=C2=A0 =C2=A0omitted from received settings.=C2=A0 Such requests = could fail,
=C2=A0 =C2=A0introducing additional latency, which this exte= nsion is intended to
=C2=A0 =C2=A0help avoid.


The proposed para= meter will be useful if an active HTTP/2 (or HTTP/3) connection to the serv= er already exists when a document with a wss:/ URL is loaded. The browser c= an then choose whether to try opening the WebSocket stream over the connect= ion, as=C2=A0the proposed SETTINGS_ENABLE_WEBSOCKETS has likely been receiv= ed by that point.

However, the proposed parameter won't be usefu= l when a browser tries to establish a new=C2=A0connection because the SETTI= NGS will not be received when a decision to use HTTP/2 or HTTP/1 is made.

Best,=C2=A0

Momoka


A new version of I-D, draft-momoka-httpbis-settings-enable-websoc= kets-01.txt
has been successfully submitted by Momoka Yamamoto and poste= d to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0draft-momoka-httpbis-settings-enable-websockets
Revision:=C2=A0 = =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SETTINGS= _ENABLE_WEBSOCKETS settings parameter for HTTP/2 and HTTP/3
Document dat= e:=C2=A0 2023-02-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual = Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/archive/id/draft-momoka-httpbis= -settings-enable-websockets-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0https://d= atatracker.ietf.org/doc/draft-momoka-httpbis-settings-enable-websockets/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft= -momoka-httpbis-settings-enable-websockets-01.html
Htmlized:=C2=A0 = =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-momoka-httpbis-settings-en= able-websockets
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://auth= or-tools.ietf.org/iddiff?url2=3Ddraft-momoka-httpbis-settings-enable-websoc= kets-01

Abstract:
=C2=A0 =C2=A0This document proposes a new H= TTP settings parameter,
=C2=A0 =C2=A0SETTINGS_ENABLE_WEBSOCKETS.=C2=A0 T= his parameter indicates whether the
=C2=A0 =C2=A0server supports bootstr= apping WebSockets over the established
=C2=A0 =C2=A0connection.

T= he IETF Secretariat


On Sat, Jan 21, 2023 at 2:07=E2=80= =AFAM Momoka Yamamoto <momoka.my6@gmail.com> wrote:
Hello,

Thanks for help= ing me to understand the motivation for this proposal.=C2=A0 Do you believe= there are existing origins that
1= . Offer SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3 AND
2. Operate= WebSocket services AND
3. Don't support WebSocket over HTTP/= 3 AND
4. Are not willing to implement WebSocket over HTTP/3
=
?

If so, then I agree we have a problem.=C2= =A0 If not, I think the best course of action is to assume that the origin&= #39;s supported "Upgrade Tokens"/":protocol values" are= independent of HTTP version, except where the IETF has ruled out support f= or a particular combination of :protocol and HTTP version.

I think this is an excellent way to look = at the landscape.

My take is that SETTINGS_ENABLE_CONNEC= T_PROTOCOL declares that a H2 or H3 server is willing to consider a request= with the :protocol pseudo-header as valid syntax. There's nothing sayi= ng what values of :protocol it has it has to support.

To = question 4, I'd say that is equally a product question as much a techni= cal one. RFC 8441 has been knocking around a while but my feeling is that d= eployments are light. There could be situations where interop or implementa= tion bugs mean WebSockets over HTTP/X behave badly while WebSockets over HT= TP/Y are fine, meanwhile WebTransport over X and Y also work fine. In that = scenario, temporarily disabling a problem variant until it can be investiga= ted and fixed is helpful, because the other variants can continue deliverin= g the feature. So allowing fine tuned control over variants, such as via an= explicit WebSocket setting, would seem to satisfy the server and stop the = client from having to guess.

<= div>For Ben's question with the 4 statements, 3 and 4 are very likely = to be yes because there are close to no servers implementing WebSockets ove= r HTTP/3 at the moment.
So then the question will be, "if a server= Operate WebSocket services, will the server never use extended CONNECT mec= hanisms such as WebTransport?" And I think this is an assumption that = should not be made.

<= div class=3D"gmail_quote">
It would be nice if a cli= ent could know if the existing HTTP/3 connection supports bootstrapping Web= Sockets.

In my vie= w, clients are free to assume this when they see a wss:// link to an origin= that offers SETTINGS_ENABLE_CONNECT_PROTOCOL in HTTP/3.
<= /blockquote>

Thanks for the earlier link to Chrome's= behaviour, it helps to frame the discussion. Quoting it for ease

&g= t; This would only be used for secure WebSockets requests, and only if ther= e is already an HTTP/2 connection where the server has already advertised s= upport for WebSockets over HTTP/2 via the HTTP/2 SETTINGS parameter defined= in the specification.

SETTINGS_ENABLE_CONNECT_PRO= TOCOL doesn't imply that bootstrapping websockets is supported IMO, whi= ch would mean this assumption doesn't strictly hold true. Content that = includes a wss:// parameter could be generated without any knowledge of the= various caches or edges features - there's typically administrative an= d business relationships between these groups.

Sin= ce Chrome only sends WebSocket over HTTP/2 on a warm connection with a SETT= ING of a particular value, changing that value to be SETTINGS_ENABLE_WEBSOC= KET instead seems like it aligns well with the current flow and wouldn'= t be too disruptive.

For reference, WebTransport over HTT= P/3 has been discussing related matters; see htt= ps://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/68. M= y understanding is that the discussion has aligned on advertising all "= ;layered settings", that is, advertising SETTINGS_ENABLE_CONNECT_PROTO= COL and SETTINGS_ENABLE_WEBTRANSPORT. Defining SETTINGS_ENABLE_WEBSOCKETS w= ould be consistent with that.

=
=C2=A0
One thing that was very confusing for me when reading RFC844= 1 was that it's about "Bootstrapping WebSockets with HTTP/2" = but it defines a general purpose HTTP/2 Extended CONNECT mechanism and SETT= INGS_ENABLE_CONNECT_PROTOCOL.=C2=A0 A new settings frame will minimise this= confusion.
And even if we follow Dragana's draft, SETTINGS_ENABLE_= WEBSOCKETS will still be needed to distinguish between advertising support = for :protocol pseudo-headers and support for WebSockets.


Momoka

<= /div> --00000000000058afc805f5be2895--