WebSocket allows more than one CONNECTING connection to the same (host, port)

[domenic]

Bug Description

RFC 6455 requires that only one WebSocket connection to a given (host, port) pair be in the CONNECTING state. Multiple connections must be queued:

https://datatracker.ietf.org/doc/html/rfc6455#section-4.1

   2.  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.

Undici does not follow this behavior.

Reproducible By

Failing web platform test: https://github.com/web-platform-tests/wpt/blob/master/websockets/constructor/014.html

Minimal Node.js repro:

const { WebSocket } = require("undici");
const { createServer } = require("http");

const server = createServer();

server.on("upgrade", async (req, socket) => {
  // Sleep 2 seconds during handshake
  await new Promise(r => setTimeout(r, 2000));

  const key = req.headers["sec-websocket-key"];
  const hash = require("crypto")
    .createHash("sha1")
    .update(key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11")
    .digest("base64");

  socket.write(
    "HTTP/1.1 101 Switching Protocols\r\n" +
    "Upgrade: websocket\r\n" +
    "Connection: Upgrade\r\n" +
    `Sec-WebSocket-Accept: ${hash}\r\n\r\n`
  );
  socket.end();
});

server.listen(0, () => {
  const port = server.address().port;
  const times = [];

  for (let i = 0; i < 2; i++) {
    const ws = new WebSocket(`ws://localhost:${port}/`);
    ws.onopen = () => {
      times.push(Date.now());
      ws.close();
      if (times.length === 2) {
        const diff = times[1] - times[0];
        console.log(`Time between onopen events: ${diff}ms`);
        console.log(diff > 1000 ? "PASS: Connections were serialized" : "FAIL: Connections were parallel");
        server.close();
      }
    };
  }
});

Expected Behavior

Time between onopen events: (some larger number)
PASS: Connections were serialized

Logs & Screenshots

Time between onopen events: 1ms
FAIL: Connections were parallel

Environment

• Node v25.2.1
• undici 7.18.2

Additional context

I might be able to emulate this with some custom dispatcher? But I'm hoping my users can already pass in a custom dispatcher, and dispatchers are hard to compose...

The ws npm package gets this correct.

[mcollina]

Does this behavior make sense in a server context?

[domenic]

I thought WebSocket was a web socket client, not server.

Is there a reason that web socket clients running on Node.js servers would not follow the RFCs that are intended to apply to all web socket clients?

[KhafraDev]

I think we should fix this

[lpinca]

The ws npm package gets this correct.

This is not true, the repro fails with ws. I also think it does not make sense in a server context where the user has control at the net.Socket level. They could create plain net.Sockets instead of WebSockets. It also limits the use cases (imagine a benchmark). The spec is vague/confusing and explicitly refers to web browser/tabs, here is the full excerpt:

When the client is to _Establish a WebSocket Connection_ given a set
of (/host/, /port/, /resource name/, and /secure/ flag), along with a
list of /protocols/ and /extensions/ to be used, and an /origin/ in
the case of web browsers, it MUST open a connection, send an opening
handshake, and read the server's handshake in response.  The exact
requirements of how the connection should be opened, what should be
sent in the opening handshake, and how the server's response should
be interpreted are as follows in this section.  In the following
text, we will use terms from Section 3, such as "/host/" and
"/secure/ flag" as defined in that section.

1.  The components of the WebSocket URI passed into this algorithm
    (/host/, /port/, /resource name/, and /secure/ flag) MUST be
    valid according to the specification of WebSocket URIs specified
    in Section 3.  If any of the components are invalid, the client
    MUST _Fail the WebSocket Connection_ and abort these steps.

2.  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.

    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.