I’m testing on both and I’m using a server of my own making (using golang and gorilla websockets lib)
I get the same behaviour - and I do send the protocol back from the server, but now that protocol can be something other than binary.
I think ideally, if the protocol isn’t specified in params the build shouldn’t include the Sec-WebSocket-Protocol header at all, but I’m not sure how flexible emscripten is.
Ok, I understand. I would just return what the client sends, regardless of what it is. One less hardcoded value 
I think ideally, if the protocol isn’t specified in params the build shouldn’t include the
Sec-WebSocket-Protocolheader at all, but I’m not sure how flexible emscripten is.
Yeah, I don’t think it’s very flexible in this regard. Also, “binary” is a perfectly acceptable default as it supports all data.
Not quite - I do need to set up the server to have the correct response header, it’s just that now it’s something reasonable (and something I can control). But that is the goal of this header anyway - to make sure that the client and server are communicating using the same schema, so hardcoded value here is not a bad thing.
The only issue with this is that the server does need to have this as a response - maybe some servers do have an option to just echo the protocol, but the tools I’m using means I do need to set up the server correctly.
Also,
websocket.send(conn, msg, {type = websocket.DATA_TYPE_TEXT})
ignores data type as TEXT on HTML5 build
Server receives the data and does nothing.
Other builds are ok.
Browser: Firefox
Tx
For all other platforms, we use a C library called wslay, where we can control the websocket control frames (such as binary/text)
On HTML5, we use the builtin implementation of Emscripten.
I’m not entirely sure how to change that.
I’ll happily take suggestions.
Server receives the data and does nothing
As I’m new to the websocket server implementations, may I ask what benefit you get from working with “text”?
Personally, when I program, I always treat all data as binary, since I’ve had too many bugs where a system has tried to be “helpful” (e.g. converting whitespaces). I find it a lot easier to reason about if I know that I have the exact payload I stored/sent.
Is your web page with https?
If yes then this makes sense, according to mixed content policies if a page was loaded over TLS then all other traffic from that page should be over TLS as well. (images, scripts, ws etc.)
If this wasn’t the case, then your HTTPS channel could potentially be pointless. As an attacker I would not be able to perform a man in the middle attack on the page itself, but if you load a resource on that page over insecure HTTP I would be able to inject things in those and compromise the entire page.
He’s using https.
We do the http/https → ws/wss conversion in the extension
Sorry to bother you guys.
Issue 1:
HTML5 build ignores DATA TYPE TEXT and sends binary.
websocket.send(conn, msg, {type = websocket.DATA_TYPE_TEXT})
Not a priority as we can easily decode the incoming data to plaintext
Issue 2: Sec-Websocket-Protocol no response:
Using Python-Websocket-Server\websocket.html on Chrome has no problem connecting to Websocket server.
Possible not to send the Sec-WebSocket-Protocol headers if we don’t provide one in the params?
Not at all. We appreciate all the help we can get to test the extension. Could I please ask that you create a ticket here: GitHub · Where software is built
Please include as much detail as possible. The code you are using to test the extension, on which platform, against which server and so on.
Hi Devs,
Will there be solution to this?
Or is abandoned?
Hi again.
Sorry, I’ve had to work on other issues during the week.
Will there be solution to this?
Not sure. I have an idea that might work, but would workaround the main functionality of Emscripten (which seems to always send that header).
I hope to be able to try it this weekend.
There’s been a lot of discussions back and forth in this long thread. I’m not even sure which issue it is we are talking of.
@James_0 I don’t see an issue created in the repository yet. Could you please create an issue?
Fixed in extension-websocket 1.5.1.