Is simultaneous WebSocket connection requests allowed?

At the IETF117 HTTP wg discussion, I had an impression that the WebSockets
discovery problem is hard to solve.

When we do not have enough "hints" to know if WebSockets is enabled on the
HTTP connection, being able to do Happy Eyeballs over multiple HTTP
versions may be a compromise solution.

A client can attempt simultaneous connections for both HTTP/2 and HTTP/3
(or HTTP/1 and HTTP/2).
The client will use the connection that successfully establishes WebSockets
first and abandon the second connection.
This saves round trips compared to creating one request and waiting for it
to fail and then doing a fallback.
This will create unneeded request and is wasteful but one might want to do
this.
The challenge is that the server must be able to handle receiving two
identical requests and return a connection, even when the client will only
use one.

For example IPv4 v.s. IPv6 racing or TCP v.s. QUIC racing is often done.

I think a clarification on whether doing Happy Eyeballs with Websockets is
okay or not is good information for implementors to know.
Because when I read RFC6455 I had the impression that it may not be allowed.


RFC 6455 Section 4.1 on Client Requirements states:

  If the client already has a WebSocket connection to the remote
>   host (IP address) identified by /host/ and port /port/ pair, even
>   if the remote host is known by another name, the client MUST wait
>   until that connection has been established or for that connection
>   to have failed. There MUST be no more than one connection in a
>   CONNECTING state. If multiple connections to the same IP address
>   are attempted simultaneously, the client MUST serialize them so
>   that there is no more than one connection at a time running
>   through the following steps.



Does this "There MUST be no more than one connection in a CONNECTING
state." in RFC6455 in purpose of:

1. Avoid giving potentially malicious code the ability to generate
arbitrary numbers of packets against a single host for a denial-of-service
attack.
2. Avoid the potential for side effects as a result of "connecting" a
websocket simultaniously. With the server not being able to recognize
between multiple requests.


When we continue reading RFC 6455, Section 4.1, it sounds like the former,

  If the client cannot determine the IP address of the remote host
>   (for example, because all communication is being done through a
>   proxy server that performs DNS queries itself), then the client
>   MUST assume for the purposes of this step that each host name
>   refers to a distinct remote host, and instead the client SHOULD
>   limit the total number of simultaneous pending connections to a
>   reasonably low number (e.g., the client might allow simultaneous
>   pending connections to a.example.com and b.example.com, but if
>   thirty simultaneous connections to a single host are requested,
>   that may not be allowed).  For example, in a web browser context,
>   the client needs to consider the number of tabs the user has open
>   in setting a limit to the number of simultaneous pending
>   connections.



  NOTE: This makes it harder for a script to perform a denial-of-
>   service attack by just opening a large number of WebSocket
>   connections to a remote host.  A server can further reduce the
>   load on itself when attacked by pausing before closing the
>   connection, as that will reduce the rate at which the client
>   reconnects.
>


  NOTE: There is no limit to the number of established WebSocket
>   connections a client can have with a single remote host.  Servers
>   can refuse to accept connections from hosts/IP addresses with an
>   excessive number of existing connections or disconnect resource-
>   hogging connections when suffering high load.



If the text "There MUST be no more than one connection in a CONNECTING
state." is there to prevent a denial-of-service attack and not a
protocol-level problem,
I think the spec should have had a weaker tone than using a "MUST".

If there is a problem with servers if clients try attempting WebSocket
requests over HTTP/2 and HTTP/3 (or HTTP/1 and HTTP/2) simultaneously I am
curious about that scenario.


Best regards,
Momoka Yamamoto
[momoka.my6@gmail.com]