Subject: Advertising WebSocket support in the HTTPS resource record

From: Dragana Damjanovic <[email-masked]>
Date: Tue, 19 Oct 2021 22:59:30 +0200

Hi,

I wrote a sort draft to support advertising WebSocket support using HTTPS
RR records.

Any feedback is welcome.

Kind Regards,
Dragana

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Oct 19, 2021 at 10:54 PM
Subject: New Version Notification for
draft-damjanovic-websockets-https-rr-00.txt
To: Dragana Damjanovic <[email-masked]>

A new version of I-D, draft-damjanovic-websockets-https-rr-00.txt
has been successfully submitted by Dragana Damjanovic and posted to the
IETF repository.

Name:           draft-damjanovic-websockets-https-rr
Revision:       00
Title:          Advertising WebSocket support in the HTTPS resource record
Document date:  2021-10-19
Group:          Individual Submission
Pages:          5
URL:
https://www.ietf.org/archive/id/draft-damjanovic-websockets-https-rr-00.txt
Status:
https://datatracker.ietf.org/doc/draft-damjanovic-websockets-https-rr/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-damjanovic-websockets-https-rr

Abstract:
   This specification introduces a way to advertise the support for the
   extended CONNECT feature that is used for running the WebSocket
   protocol over a single stream of an HTTP/2 and HTTP/3 connection
   using HTTPS resource records [HTTPSRR].

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Oct 2021 17:53:39 -0400

Thanks for this draft, Dragana!

As a matter of IETF procedure, I think it's best to avoid specifying a
number for the SvcParam in your draft at least until it is adopted by a
working group.  (Right now we are in a slightly awkward position, as the
SvcParam registry will be First-Come-First-Served, but it does not yet
exist.)  Your chosen value, for example, happens to collide with
draft-ietf-dnsop-svcb-dns.

On the technical side, I wonder if you've looked at
https://datatracker.ietf.org/doc/html/draft-vvv-httpbis-alps?  That
proposal would provide the SETTINGS frame earlier in the handshake,
achieving the same goal of avoiding this delay.  Compared to delivery over
DNS, it has some important benefits.  For example, it reduces the amount of
information that needs to be synchronized between HTTP servers and their
DNS zones, and encompasses any future HTTP SETTINGS as well.

---

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 20 Oct 2021 10:36:46 +0200

Hi,

> draft-ietf-dnsop-svcb-dns.

Thank you. I will fix it and I will remember for further drafts.

> DNS zones, and encompasses any future HTTP SETTINGS as well.

The draft will eliminate some of this delay, but the TLS handshake still
needs to be completed. There can be situation where it is possible to use
HTTP/3 and HTTP/2, the client could choose to try HTTP/3, fallback to
HTTP/2 and than to HTTP/1.1 or skip one of the steps.

Dragana

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Oct 2021 12:06:52 -0400

> On Tue, Oct 19, 2021 at 11:53 PM Ben Schwartz <[email-masked]> wrote:
...

> HTTP/2 and than to HTTP/1.1 or skip one of the steps.

This is an interesting observation, but it seems like this only works if
the client can rely on HTTP/2-WebSocket endpoints to publish the
"extended-connect" flag.  For example, if there are
HTTP/2-WebSocket endpoints deployed today with HTTPS records, clients
implementing this specification would lose access to those endpoints (until
they update their HTTPS records).

This change also creates an HTTP/2->HTTP/1.1 downgrade attack.  A DNS
intermediary could delete this flag, in order to force clients to use
HTTP/1.1 instead of HTTP/2.  In general, HTTPS records are designed to
prevent this downgrade attack.  (I don't know if this raises security
concerns for WebSockets.)

Rather than optimize the performance of origins that use WebSockets, and
support HTTP/2 and HTTP/3, but only support WebSockets on HTTP/1.1, I would
prefer to encourage server deployment of WebSockets support on all HTTP
versions.  We could also consider documenting a parallel connection
strategy for clients, if it's important to avoid a fallback delay.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Oct 2021 17:27:05 +0100

> strategy for clients, if it's important to avoid a fallback delay.

That's an interesting point. Extended CONNECT isn't just for Websockets, as
we are seeing with MASQUE developments. So I would expect cases where a
server only :protocol connect-udp and NOT websockets, or vice versa. So to
make this type of thing work, it seems like what is needed is a protocol
hint (singular or a list) too.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Oct 2021 12:35:18 -0400

On Wed, Oct 20, 2021 at 12:27 PM Lucas Pardue <[email-masked]>
wrote:

> That's an interesting point. Extended CONNECT isn't just for Websockets,
> as we are seeing with MASQUE developments. So I would expect cases where a

My expectation is that the supported :protocols are handled like the
supported paths: the client knows which one it needs from the URI (e.g.
wss://..., https://.../foo), and the origin had better support it if it is
advertising those URIs anywhere.  I don't think we need a pre-connection
hint about the supported :protocols.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Oct 2021 17:54:43 +0100

On Wed, Oct 20, 2021 at 5:35 PM Ben Schwartz <[email-masked]> wrote:

> wss://..., https://.../foo), and the origin had better support it if it
> is advertising those URIs anywhere.  I don't think we need a pre-connection

I don't follow. That implies the server would present different pages to a
client based on the protocol that the client connected with. That sounds
hard and I'm not sure it would help much. In today's, a client that doesn't
support WebSocket over H2 would simply see wss:// and open a new HTTP/1.1
connection for the upgrade. We should hope that a H2 websocket client that
sees wss:// would try to create the websocket over a connection that
support it, or an H3 websocket client see wss:// and does likewise. This
gets a bit murky when Alt-Svc is thrown in the mix.

A DNS record or an ALPS value only tells the H2 client that it is allowed
to send a request that contains the :protocol pseudo-header. If it does,
and finds that the server doesn't support the protocol that it wants, then
the request will fail, and the client wasted its time. Saving time seems to
be what this proposal is about.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Oct 2021 13:27:32 -0400

On Wed, Oct 20, 2021, 12:54 PM Lucas Pardue <[email-masked]>
wrote:

> client based on the protocol that the client connected with.
>

No, I'm trying to say the opposite of that.  These things are properties of
the origin, not any specific endpoint or transport.

...

> If it does, and finds that the server doesn't support the protocol that it
> wants, then the request will fail, and the client wasted its time.
>

Sure.  That's just like a 404, and the solution is the same: don't tell
your users to send requests that your origin doesn't support.

---

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 20 Oct 2021 21:05:00 +0200

> hint about the supported :protocols.

In case of WebSockets the url is wss://  and that can be serve using
HTTP/1.1, HTTP/2 or HTTP/3 but a particular server may not support WS over
HTTP/2 or WS over HTTP/3

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Oct 2021 20:03:14 +0100

On Wed, Oct 20, 2021 at 6:27 PM Ben Schwartz <[email-masked]> wrote:

>> I don't follow. That implies the server would present different pages to
>> a client based on the protocol that the client connected with.
>>
>
> No, I'm trying to say the opposite of that.  These things are properties
> of the origin, not any specific endpoint or transport.
>
> ...
>
>> If it does, and finds that the server doesn't support the protocol that
>> it wants, then the request will fail, and the client wasted its time.
>>
>

Again I don't know how you can make these two things align. There's a
difference between "my origin supports retrieving a resource using HTTP"
and a client and server actually selecting the HTTP version to use for
that. This is even more true when intermediaries are in the mix, because
the page that includes a URL could be very far removed from the (multi) CDN
that is responsible for the details of the connection that is formed
between it and a client. We purposefully avoided encoding the HTTP version
in the scheme, but it kind of all works ok due to Alt-Svc.

With WebSocket, the origin could support only WebSocket via HTTP/1.1
upgrade. An intermediary could support WebSocket over some of HTTP/1.1,
HTTP/2 or HTTP/3; converting to what the origin uses on the backend. It's
very hard for an origin to react to permutations of these setups,
especially across different providers. Just hoping everyone enables all
forms of support doesn't seem realistic to me.

Tangent:

How to respond to a client when SETTINGS_ENABLE_CONNECT_PROTOCOL is enabled
but a value of ":protocol" is not supported is IMO actually pretty poorly
defined in RFC 8441. And draft-ietf-masque-connect-udp doesn't really say
much either. If a server sends 404, it could imply the web socket resource
doesn't exist at all. That's not true, it exists but can only be accessed
using a specific HTTP version.

Cheers
Lucas

---

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 20 Oct 2021 21:14:18 +0200

On Wed, Oct 20, 2021 at 9:03 PM Lucas Pardue <[email-masked]>
wrote:

>>>> wss://..., https://.../foo), and the origin had better support it if
>>>> it is advertising those URIs anywhere.  I don't think we need a
>>>> pre-connection hint about the supported :protocols.
>>>>
>>>
I agree with this point. I think my messages was sent at the almost same
time as this.

I have open an issue at w3c about adding hint when opening WebSockets as
well, but I am not sure that would salve all the problems:
https://github.com/whatwg/html/issues/7243

> Tangent:
>
> How to respond to a client when SETTINGS_ENABLE_CONNECT_PROTOCOL is
> enabled but a value of ":protocol" is not supported is IMO actually pretty
> poorly defined in RFC 8441. And draft-ietf-masque-connect-udp doesn't
> really say much either. If a server sends 404, it could imply the web
> socket resource doesn't exist at all. That's not true, it exists but can
> only be accessed using a specific HTTP version.
>
>
This is a very good point I think we need more specific
SETTINGS_ENABLE_CONNECT_PROTOCOL or a new response code somewhat similar to
421 (but it is not the same).

 dragana

Cheers

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Oct 2021 16:05:11 -0400

On Wed, Oct 20, 2021 at 3:03 PM Lucas Pardue <[email-masked]>
wrote:

> between it and a client.

Yes.  That's why you MUST NOT tell a user to use a :protocol or path unless
it is reachable on all the server endpoints for your origin, including all
relevant supported HTTP versions.

> We purposefully avoided encoding the HTTP version in the scheme, but it
> kind of all works ok due to Alt-Svc.
>
> especially across different providers.
>

Yes.  We've walked ourselves into an ugly corner here by allowing some
aspects of the origin to differ between versions.

> Just hoping everyone enables all forms of support doesn't seem realistic
> to me.
>

With extended-connect, we've created a problem, as Dragana highlighted.  I
think allowing the supported :protocol set to vary arbitrarily between HTTP
versions, with some hint mechanism to tell you what's supported where,
would make this worse, not better.

My preferred solution would be to say:
 * ALPS can be used to get the SETTINGS sooner.
 * Clients that need extended-connect (e.g. WebSockets, likely MASQUE)
should fall back to HTTP/1.1 if the server doesn't support
extended-connect.  If performance is crucial, clients may start HTTP/1.1 in
parallel with HTTP/2+, but must not use it until after receiving the
SETTINGS frame.
 * Servers should enable extended-connect on all HTTP/2+ versions or none
 * Any :protocol advertised to clients must be supported on all
extended-connect endpoints (except if it is deemed incompatible with some
HTTP version).
 * If the IETF deems a :protocol value incompatible with a specific HTTP
version, this cannot later be reversed.
 * Clients must not fall back to a lower HTTP version if CONNECT returns an
error code.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Oct 2021 21:21:25 +0100

> would make this worse, not better.

I'm not tied to any particular solution here, it seems we are agreeing on
the problems though, which is good.

>  * Clients must not fall back to a lower HTTP version if CONNECT returns
> an error code.
>

I can think of good reasons for a server to support only "websocket" and
not "connect-udp", or vice versa. Either because their library was written
before capsules existed or because they outright disable some form of
protocol they don't want a particular server to satisfy. For
intermediaries, what the origin is telling the client can be completely
outside their control. Even ignoring intermediaries, there's often a gulf
between webdevs and the server infra folk. Unless there is a scheme like
"wss-h1://", "wss-h2://" etc. then I can't see a way to link these two up
robustly (FWIW I think putting versions in schemes is bad).

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 20 Oct 2021 16:34:30 -0400

On Wed, Oct 20, 2021 at 4:21 PM Lucas Pardue <[email-masked]>
wrote:

>> With extended-connect, we've created a problem, as Dragana highlighted.
>> I think allowing the supported :protocol set to vary arbitrarily between
>> HTTP versions, with some hint mechanism to tell you what's supported where,
> not "connect-udp", or vice versa.
>

I can think of good reasons for an "origin" to support only one :protocol.
I don't think we should allow a single origin to support "websocket" on H2
but not H3, and "connect-udp" on H3 but not H2.  That's the case I'm trying
to rule out, because it would greatly complicate the required client
behavior.

> For intermediaries, what the origin is telling the client can be
> completely outside their control.
>

That's fine.  You serve a 4XX.  Whoever told clients to use
wss://origin-that-doesn't-always-support-websockets is at fault.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Oct 2021 22:19:21 +0100

On Wed, Oct 20, 2021 at 9:34 PM Ben Schwartz <[email-masked]> wrote:

> I can think of good reasons for an "origin" to support only one
> :protocol.  I don't think we should allow a single origin to support
> "websocket" on H2 but not H3, and "connect-udp" on H3 but not H2.  That's
> the case I'm trying to rule out, because it would greatly complicate the
> required client behavior.
>

That's the exact case I'm thinking about. There might be little value
trying to backport connect-udp to H2 for some kinds of services, it might
be better to fallback to plain old CONNECT. Meanwhile, someone might have
websocket support left as a TODO for HTTP/3. Requiring feature parity
across all versions just increases the bar to experimentation or deploying
new versions of things.

> wss://origin-that-doesn't-always-support-websockets is at fault.

But there's not satisfactory means to correct that fault. Take for example
a website today that provides index.html including a wss:// link, clients
are already able to handle loading the document over H2 and opening the
WebSocket via HTTP/1.1. If the response contains and Alt-Svc for h3, then
the document can be loaded over H3 and the WebSocket via HTTP/1.1. Now, the
server starts enabling H3 extended connect for some other ":protocol" that
is part of an unrelated experiment. A client then attempts to use an H3
connection for websocket and receives a 4xx; following your suggestion, the
client can never open the websocket. The only recourse is to disable
HTTP/3, which is worse than the situation we started with.

It would be nice to avoid complexity. But the proposal seems to me like an
all or nothing bet, which doesn't seem too accommodating to the HTTP server
ecosystem.

---

From: Dragana Damjanovic <[email-masked]>
Date: Thu, 21 Oct 2021 09:19:35 +0200

On Wed, Oct 20, 2021 at 11:19 PM Lucas Pardue <[email-masked]>
wrote:

>>>> With extended-connect, we've created a problem, as Dragana
>>>> highlighted.  I think allowing the supported :protocol set to vary
>>>> arbitrarily between HTTP versions, with some hint mechanism to tell you
>>>> what's supported where, would make this worse, not better.
>>>>
>>>
>>> I'm not tied to any particular solution here, it seems we are agreeing
>>> on the problems though, which is good.
>>>
>>>
>>>>  * If the IETF deems a :protocol value incompatible with a specific
>>>> HTTP version, this cannot later be reversed.
>>>>  * Clients must not fall back to a lower HTTP version if CONNECT
>>>> returns an error code.
>>>>
>>>
I think as well that this is too much. Thee should be graceful way to deal
with this. If we have one settings for all feature that use the extended
CONNECT, there should be a way for a server to gently say that it does not
support that particular protocol. Leaving everything to a good
configuration of a whole system with a lot of moving parts is not good.

dragana

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 21 Oct 2021 10:05:28 +0200

> Am 20.10.2021 um 23:19 schrieb Lucas Pardue <[email-masked]>:
> 
> That's the exact case I'm thinking about. There might be little value trying to backport connect-udp to H2 for some kinds of services, it might be better to fallback to plain old CONNECT. Meanwhile, someone might have websocket support left as a TODO for HTTP/3. Requiring feature parity across all versions just increases the bar to experimentation or deploying new versions of things.

+1

Some servers are also configurable in their protocol implementations. H1, H2 and H3 implementations may not be aware of each others capabilities. Or a particular implementation's feature is flawed and disabled until patched. It would be good to allow other H* implementations to still be available as fallback.

Stefan

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Oct 2021 10:46:25 -0700

In theory, in terms of HTTP semantics, if someone mints wss://
websocket.example.org and sends an h3 Alt-Svc for websocket.example.org,
then that means that the client can use WebSocket over HTTP/3.

However, in practice, as Stefan points out, that might not always hold. In
the scenario where someone accidentally misconfigured their server by not
having enough communication between h1/h2/h3, they can rectify the
situation by replying with HTTP status code 421. That'll cause the client
to fallback to an earlier version of HTTP.

This all sounds like we have a semantically coherent answer, with a
pragmatic fallback in case of misconfiguration. The only downside is that
the fallback might waste time. Given that the fallback is caused by
misconfiguration, I'm not sure there's value in creating a new mechanism to
avoid it: if you really really care about performance, configure your
server correctly.

The proposed mechanism using HTTPS records requires the server operators to
make changes to their DNS which isn't always possible. If a server operator
can/wants to do this, they can just as easily create a new hostname
websocket-but-only-on-h1.example.org hostname and not advertise HTTP/3
support for that origin.

David

On Thu, Oct 21, 2021 at 1:09 AM Stefan Eissing <[email-masked]>
wrote:

>
>
> > Am 20.10.2021 um 23:19 schrieb Lucas Pardue <[email-masked]
> >:
> >
> Some servers are also configurable in their protocol implementations. H1,
> H2 and H3 implementations may not be aware of each others capabilities. Or
> a particular implementation's feature is flawed and disabled until patched.
> It would be good to allow other H* implementations to still be available as
> fallback.
>
> Stefan
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Oct 2021 19:06:25 +0100

> to fallback to an earlier version of HTTP.

I don't think 421 is the right status here. The example I would actually
use is a document loaded from https://example.com/index.html that includes
wss://example.com/chat. If this is loaded via an H2 connection, which
supports extended connect for :protocol connect-udp but not websocket, then
the CONNECT request should fail but 421 is a status about authority
(generally caused by coalescing, a whole additional ballgame), and there is
no authority problem here. The client fallback to a fresh connection would
have to be careful to use HTTP/1.1.

> avoid it: if you really really care about performance, configure your

There might be a path, but it sounds like abusing the wrong status code is
not semantically coherent :)

>
> The proposed mechanism using HTTPS records requires the server operators
> to make changes to their DNS which isn't always possible. If a server
> operator can/wants to do this, they can just as easily create a new
> hostname websocket-but-only-on-h1.example.org hostname and not advertise
> HTTP/3 support for that origin.
>

That sounds a lot easier than it is. And it is a solution for a problem
that doesn't exist for most WebSocket deployments today. If the answer to
making HTTP/2 WebSockets (as an example) work is to update an entire fleet
and change all the URLs, the simplest solution approach is to really never
ship WebSockets over a version other than HTTP/1.1.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 21 Oct 2021 15:35:22 -0700

On Thu, Oct 21, 2021 at 11:10 AM Lucas Pardue <[email-masked]>
wrote:

>> However, in practice, as Stefan points out, that might not always hold.
>> In the scenario where someone accidentally misconfigured their server by
>> not having enough communication between h1/h2/h3, they can rectify the
> use is a document loaded from https://example.com/index.html that
> includes wss://example.com/chat. If this is loaded via an H2 connection,
> which supports extended connect for :protocol connect-udp but not
> websocket, then the CONNECT request should fail but 421 is a status about
> authority (generally caused by coalescing, a whole additional ballgame),
> and there is no authority problem here. The client fallback to a fresh
> connection would have to be careful to use HTTP/1.1.
>

For HTTP/2 I think instead of 421, we could use HTTP_1_1_REQUIRED. Does
that sound right?

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Oct 2021 23:58:22 +0100

> For HTTP/2 I think instead of 421, we could use HTTP_1_1_REQUIRED. Does

In H3, the equivalent error code is H3_VERSION_FALLBACK. These might
possibly work, but it makes a big assumption that HTTP/1.1 is the solution.
Stream errors in direct reaction to a syntactically valid request are
specced but can be a bit thorny to handle in implementations.

It could just be that one server instance that is authoritative, is not
able to serve the request at the time. As I said upthread, there seems to
be an omission of a status code or error code that articulates this simply,
and perhaps a header that could be used to carry the list of actual support
protocols (like Upgrade can do, but I think is prohibited in H2 or H3).

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 21 Oct 2021 22:07:59 -0400

I see deep implications here.

If an origin advertises HTTP/3 support, it is saying "this origin is
compatible with HTTP/3-only clients".  HTTP/3 clients are not required to
implement HTTP/2 or HTTP/1.1.

WebSockets is a special case because it's old, and we can carve out some
limited fallback due its legacy status, but in general I think we need to
stick to this rule.  Otherwise, the HTTP versions cease to be independent.
Instead, we're effectively requiring clients to support _all_ HTTP versions.

Also, I have doubts about the claims of server simplification.  In order to
tell the client "sorry, you need to use HTTP/X instead", the different
server versions have to be pretty tightly coupled, to know which protocols
are supported on which versions.  At that point, you might as well just
proxy the request to the version that knows how to handle it.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 22 Oct 2021 17:54:53 +1100

> I see deep implications here.

Same.

> compatible with HTTP/3-only clients".  HTTP/3 clients are not required 
> to implement HTTP/2 or HTTP/1.1.

I don't think that that is quite right.  You might *like* that to be the case, but it is not how things work.

We could do as you suggest, but that forces an origin that deploys a given protocol version to support all of its resources - and the ways in which those resources operate - over that version as well.

That's fine in principle, but - as of this moment - that is an impossible requirement to fulfill.  Websockets over HTTP/3 is a twinkling in the eye of its parents and - by all practical measures - does not exist.

This pattern will continue as long as we continue to invent "X over HTTP" with weird interaction methods (think WebTransport and MASQUE).  Those protocols might get a fresh definition for the new HTTP version, but I don't think we can guarantee that they will all have definitions at the time you might first deploy that new HTTP version.

This attitude effectively means these special "X over HTTP" protocols always need to be deployed on a different domain name.  The upgrade cycle of HTTP would not affect them.

This idea that we might want to avoid HTTP-version downgrade for these adjunct protocols is fine in theory, but I think that it's not doing us any favours.

I don't disagree with your other conclusions; I find the idea that you might need to say "please use HTTP/X for this combination of resource and feature" is quite horrifying.  I also don't have a concrete proposal for how to deal with it.  I'm interested in hearing what people come up with.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 22 Oct 2021 12:27:35 -0400

On Fri, Oct 22, 2021 at 3:06 AM Martin Thomson <[email-masked]> wrote:
...

> We could do as you suggest, but that forces an origin that deploys a given
> protocol version to support all of its resources - and the ways in which
> those resources operate - over that version as well.
>
> That's fine in principle, but - as of this moment - that is an impossible
> requirement to fulfill.  Websockets over HTTP/3 is a twinkling in the eye
> of its parents and - by all practical measures - does not exist.
>

Yes.  I think WebSockets is a special case, though.

> This pattern will continue as long as we continue to invent "X over HTTP"
> with weird interaction methods (think WebTransport and MASQUE).

I don't think WebTransport or MASQUE will have these problems.  They'll
both be defined (or explicitly not defined) for all existing HTTP versions
on Day 1.  Similarly, any future HTTP versions can incorporate (or
explicitly reject) all pre-existing protocols.

We only have a problem if, for a given :protocol, the client and server
might disagree about whether it is defined for a given HTTP version.  If a
disagreement occurs, it's our fault, for changing our minds about what is
allowed where.

  Those protocols might get a fresh definition for the new HTTP version,
> but I don't think we can guarantee that they will all have definitions at
> the time you might first deploy that new HTTP version.
>

I don't see why we can't guarantee that.

---

From: Dragana Damjanovic <[email-masked]>
Date: Sat, 23 Oct 2021 22:00:13 +0200

On Fri, Oct 22, 2021 at 6:34 PM Ben Schwartz <[email-masked]> wrote:

>> We could do as you suggest, but that forces an origin that deploys a
>> given protocol version to support all of its resources - and the ways in
>> which those resources operate - over that version as well.
>>
I am not sure here. The fallback for WebTransport is not finalize yet, if
we have  fallback that can use HTTP/1.1 or HTTP/2(if I am not wrong it
sounded as if it going in this diraction) the server side may deploy just
one version. The clients will be in the same situation as with WebSockets.
... we can also say this is a new thing and it should be deploy on a
separate origin for easier configuration.

dragana