feat: add sec-websocket-version to response headers when request sec-websocket-version is invalid

[samuel871211]

While test locally with postman, send invalid sec-websocket-version, I found that the server doesn't include sec-websocket-version: 13,8 in response headers

1. Based on MDN Document
   https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-WebSocket-Version

If the server doesn't support the version, or any header in the handshake is not understood or has an incorrect value, the server should send a response with status [400 Bad Request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400) and immediately close the socket. It should also include Sec-WebSocket-Version in the 400 response, listing the versions that it does support.

2. Based on RFC6455
   https://datatracker.ietf.org/doc/html/rfc6455#section-4.4

The following example demonstrates version negotiation described above:

      GET /chat HTTP/1.1
      Host: server.example.com
      Upgrade: websocket
      Connection: Upgrade
      ...
      Sec-WebSocket-Version: 25

   The response from the server might look as follows:

      HTTP/1.1 400 Bad Request
      ...
      Sec-WebSocket-Version: 13, 8, 7

   Note that the last response from the server might also look like:

      HTTP/1.1 400 Bad Request
      ...
      Sec-WebSocket-Version: 13
      Sec-WebSocket-Version: 8, 7

   The client now repeats the handshake that conforms to version 13:

      GET /chat HTTP/1.1
      Host: server.example.com
      Upgrade: websocket
      Connection: Upgrade
      ...
      Sec-WebSocket-Version: 13

This PR add sec-websocket-version to response headers when request sec-websocket-version is invalid.

• npm run lint
• npm run test
• npm run integration

[lpinca]

FWIW, given that

The request MUST include a header field with the name
|Sec-WebSocket-Version|.  The value of this header field MUST be
13.

I think it makes sense to drop support for version 8, but it is a breaking change.

[lpinca]

Thank you.

[samuel871211]

FWIW, given that

The request MUST include a header field with the name
|Sec-WebSocket-Version|.  The value of this header field MUST be
13.

I think it makes sense to drop support for version 8, but it is a breaking change.

I thought so. Do you plan to drop support for version 8?

[lpinca]

Maybe, but it is not a priority. Supporting version 8 does not cost anything.

$ git grep '=== 8'
lib/websocket-server.js:          req.headers[`${version === 8 ? 'sec-websocket-origin' : 'origin'}`],

[samuel871211]

Agree, since it does not dramatically reduce the bundle size of this project, and may require a major version bump, I don't see the benefit of it.

[lpinca]

The only valid reason is strict compliance with RFC 6455, but it does not worth a major version bump per se. It should be added to the list of breaking changes for the next major version.