Force ignore Sec-WebSocket-Protocol in libwebsocket server mode.

[exploman]

As a server, in order to maintain maximum compatibility, I only provide one service for one port. I hope to force the Sec WebSocket Protocol to be ignored, whether the client fills it with an empty space or any other value. However, I checked the lws_process_ws_upgrade function and it definitely forces the matching of sub protocol names in this function. I always get logs like this "No supported protocol"

[lws-team]

I hope to force the Sec WebSocket Protocol to be ignored

As a ws thing, that is not actually legal. If you asked for an explicit protocol name that the server doesn't support, it should fail the upgrade (as lws does).

The best way is just support your protocol name and insist to see that name from the clients. That allows you to add additional protocol names, perhaps versioned ones, on one vhost / server.

If you want to provide a patch that forces ignoring any information that was sent, with a vhost / server option, I'll consider adding it.

[exploman]

As a ws thing, that is not actually legal. If you asked for an explicit protocol name that the server doesn't support, it should fail the upgrade (as lws does).

I completely agree with this. We gave up this feature just for better compatibility. I hope to have a configuration on a specified vshost/server that does not validate Sec WebSocket Protocol.

Many companies provide WS APIs that do not verify the Sec WebSocket Protocol. So the client complained why it works to connect to other servers but not mine. Based on the current API, I cannot modify the original headers in the callback, so I cannot overwrite this HTTP header with '0'

[lws-team]

Many companies provide WS APIs that do not verify the Sec WebSocket Protocol.

I sincerely doubt there is this mass deviation from the standard going on.

There is the option (in the standard) for the client to not provide a subprotocol header. Then, the server is "dumb" and since it only supports a single protocol, it binds to that and returns that name. In Lws client you just leave the .protocol NULL, and set .local_protocol_name to the local protocol name you want to bind to in the client info struct. It's a poor way to do it because a) you can only offer a single protocol per vhost, and b) you can't version the protocol cleanly so old clients have a grace period using the old protocol at the server.

It seems a waste of time to worry about people choosing the wrong name. If they bothered to ask for a specific protocol, it is dangerous that they might get something else, unaware.

[exploman]

You are correct, I agree with the standard approach, and I understand the role of sub protocols. Just some developers or library implementations randomly filled in Sec WebSocket Protocol. WebSocket has powerful capabilities, but sometimes we just use WebSocket to replace TCP as a transmission channel. There is an AWS API message exchange here, and the client complained to us that connecting to AWS works, but connecting to my server doesn't work.

GET /stream-transcription-websocket?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxxx%2F20240322%2Fus-west-2%2Ftranscribe%2Faws4_request&X-Amz-Date=20240322T052923Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&language-code=en-US&media-encoding=pcm&sample-rate=16000&X-Amz-Signature=xxxxx HTTP/1.1
Connection: Upgrade
Host: transcribestreaming.us-west-2.amazonaws.com
Sec-WebSocket-Key: xxx
Sec-WebSocket-Protocol: websocket
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0

HTTP/1.1 101 Switching Protocols
connection: upgrade
sec-websocket-accept: xxx
Strict-Transport-Security: max-age=31536000
upgrade: websocket
x-amzn-RequestId: xxx
x-amzn-SessionId: xxx

Life is difficult, and as a service provider, sometimes we need to accommodate our customers. Forcefully ignoring Sec WebSocket Protocol is only for greater flexibility(Not recommended option), and libwebsocekts may not implement this. I have already asked the client to modify protocol name.