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

#1

Hi,
I get this error after

  1. Project > Bundle > HTML5 Application
    and
  2. Project > Build HTML5

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

Works fine on: Project > Build

Thanks in advance.

0 Likes

#2

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

2 Likes

#3

Ya,
Binary

0 Likes

#4

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) ...
1 Like

#5

Still having problem connecting:
It shows chat now:

But, still won’t connect:

0 Likes

#6

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://”.

0 Likes

#7

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.

0 Likes

#8

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?

0 Likes

#9

Don’t hate me, but same with other service

1 Like

#10

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?

0 Likes

#11

Same,

0 Likes

#12

Wow,
works on Firefox

All above errors are Chrome based.
:S

1 Like

#13

Wow, yeah I’m on Firefox :confused:
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
0 Likes

#14

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.

1 Like

#15

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?

1 Like

#16

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.

0 Likes

#17

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

1 Like

#18

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.

0 Likes

#19

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

Tx

0 Likes

#20

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?

0 Likes