Websocket Sec-Websocket-Protocol no response was received (SOLVED)

James_0 · November 10, 2020, 7:44am

Hi,
I get this error after

Project > Bundle > HTML5 Application
and
Project > Build HTML5

What am I missing?
I tried with and without the params.

Works fine on: Project > Build

Thanks in advance.

Alesis · October 31, 2020, 4:10am

I’m guessing you’re running into the HTML5 build sub-protocol bug. The quick workaround is making sure your server accepts/responds to the binary sub-protocol, because that is what it is set to (you can check your network inspection tool to confirm).

James_0 · October 31, 2020, 11:29am

Ya,
Binary

Mathias_Westerdahl · October 31, 2020, 3:01pm

Hi @James_0!

I just released a new version of the extension, where you can define the protocol parameter. E.g.

local params = {
    timeout = 3000,
    protocol = "chat"
}
self.ws = websocket.connect(url, params, function(self, conn, data) ...

James_0 · October 31, 2020, 3:31pm

Still having problem connecting:
It shows chat now:

But, still won’t connect:

Mathias_Westerdahl · October 31, 2020, 3:22pm

I see that you are calling into a “wss://” url.
That will only work if the client is calling from a “https://”.

Is that the case, or are you using a local server (e.g. from “Build and run”) ?
You can try connecting to a “ws://”.

James_0 · October 31, 2020, 3:26pm

True,
All https here.

I also noticed it auto select ws on localhost and wss when I upload it to my server.

Webserver is running Python-Websocket
The websocket.html provided connects well.
Any other Defold build works great.
Just the HTML builds are creating problem.

Mathias_Westerdahl · October 31, 2020, 3:36pm

This is indeed a bit strange.
On the HTML5 platform, all the sockets are automatically upgraded to websocket. Apart from setting the protocol now, we don’t do anything else websocket related for the connection.

What if you connect to another service, like “wss://echo.websocket.org”, does it succeed then?

James_0 · October 31, 2020, 3:39pm

Don’t hate me, but same with other service

Mathias_Westerdahl · October 31, 2020, 3:41pm

Don’t hate me, but same with other service

Heh, no worries!

And, what if you try a local build, and connecting towards “ws://echo.websocket.org” (non secure)? I’m wondering if there’s a discrepancy between ws/wss somethere?

James_0 · October 31, 2020, 3:44pm

Same,

James_0 · October 31, 2020, 3:45pm

Wow,
works on Firefox

All above errors are Chrome based.
:S

Mathias_Westerdahl · October 31, 2020, 3:51pm

Wow, yeah I’m on Firefox
Hmm, I wonder what could cause this

Edit:
Googling a bit hints that it might be something to do with the Sec-WebSocket-Extensions.

Here’s the response from Firefox:

GET / HTTP/1.1
Host: echo.websocket.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://localhost:8000
Sec-WebSocket-Protocol: binary
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: iz7dIk4ODtZZH+xLdRAL3Q==
Connection: keep-alive, Upgrade
Cookie: _ga=GA1.2.931767768.1597825628
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

James_0 · October 31, 2020, 3:52pm

Tracing the error on Chrome, google found me this:

Esp this:
Passing credentials via Sec-WebSocket-Protocol is a common workaround for WebSocket authentication for web based applications since browsers do not support sending custom headers while connection initiation.

If you are passing a value via Sec-WebSocket-Protocol header, your server has to return the same header/value pair back to the client.

Since Sec-WebSocket-Protocol header is not intended for passing credentials to the WebSocket server, you have to play by its rules and treat it like a protocol and fulfill its requirements.

Mathias_Westerdahl · October 31, 2020, 3:56pm

Good find!

Ok, so I interpret this as that Chrome expected your server to return the same value in the Sec-WebSocket-Protocol as was sent?

Alesis · October 31, 2020, 3:58pm

Yes, that’s why the now fixed bug was so annoying (thanks for that by the way!) - I had to set the server to a binary sub-protocol (which conceptually didn’t make sense) for the HTML5 build to work. Firefox seems to ignore this though so I’m not sure how you would possible make this a legitimate authentication process.

Mathias_Westerdahl · October 31, 2020, 3:59pm

I think this is different?
This is the Chrome browser expecting your websocket server to return the same value as was sent to it (regardless of the actual protocol).

Alesis · October 31, 2020, 4:04pm

Yes, which meant I had to have the websocket server send binary before, since that was what any HTML5 build had. Now I can set it up to be whatever I want through params. Also, not sure what you mean by “regardless of the actual protocol” - the Sec-WebSocket-Protocol is the name of the sub-protocol for websockets and doesn’t actually enforce anything in itself - which is why even though I set it to binary previously I just sent around json messages anyway.

James_0 · October 31, 2020, 4:07pm

Are you using Chrome or Firefox?
Also, which websocket server are you using ?

Tx

Mathias_Westerdahl · October 31, 2020, 4:09pm

According to this, you didn’t have to reply “binary” (hardcoded), but just whatever the client sent to the server (it just happened to be “binary”).
Now when you send “chat”, it seems it expects to get “Sec-WebSocket-Protocol: chat”?
That’s how I interpret the comment and error at least.

Are you saying that you don’t get the same behavior as James on Chrome + HTML5, now that you don’t send the Sec-WebSocket-Protocol back from the server?