Client disconnects immediately after connection

[1Hyena]

uname -a output:
Linux Courage 4.14.74-1-MANJARO #1 SMP PREEMPT Fri Oct 5 14:16:52 UTC 2018 x86_64 GNU/Linux

I have the below code running in Chromium:

try{
    var ws = new WebSocket("ws://"+SNDC_HERALD_HOST+":"+SNDC_HERALD_PORT,  ['binary', 'base64']);

    ws.onopen = function() {
        // Web Socket is connected, send data using send()
        SNDC_HERALD_CONN = ws;

        setTimeout(function() {
            sndc_herald_start();
        }, 100);
    };

    ws.onmessage = function (evt) {
        var blob = evt.data;

        var reader = new FileReader();

        reader.onload = function(e) {
            var text = reader.result;
            sndc_herald_receive_output(text);
            SNDC_HERALD_CMD = SNDC_HERALD_CMD + text;

            while (true) {
                var before = SNDC_HERALD_CMD.length;
                SNDC_HERALD_CMD = sndc_herald_interpret(SNDC_HERALD_CMD);
                if (before <= SNDC_HERALD_CMD.length) break;
            }
        }

        reader.readAsText(blob);
    };

    ws.onerror=function(event){
        sndc_herald_alert("WebSocket error.");
    }

    ws.onclose = function() {
        // websocket is closed.
        sndc_herald_alert("Connection lost.");
        SNDC_HERALD_CONN = null;
        SNDC_HERALD_CONNECTING = false;
    };
}
catch (e) {
    sndc_herald_alert(e);
}

And this is what I get logged by the websockify process:

[hyena@Courage websockify]$ ./run -v --traffic 7007 127.0.0.1:17777
/home/hyena/Desktop/GIT/websockify/websockify/websocket.py:30: UserWarning: no 'numpy' module, HyBi protocol will be slower
  warnings.warn("no 'numpy' module, HyBi protocol will be slower")
WebSocket server settings:
  - Listen on :7007
  - No SSL/TLS support (no cert file)
  - proxying from :7007 to 127.0.0.1:17777
127.0.0.1: new handler Process
127.0.0.1 - - [19/Oct/2018 11:18:40] "GET / HTTP/1.1" 101 -
127.0.0.1 - - [19/Oct/2018 11:18:40] 127.0.0.1: Plain non-SSL (ws://) WebSocket connection
127.0.0.1 - - [19/Oct/2018 11:18:40] connecting to: 127.0.0.1:17777

Traffic Legend:
    }  - Client receive
    }. - Client receive partial
    {  - Target receive

    >  - Target send
    >. - Target send partial
    <  - Client send
    <. - Client send partial
}.127.0.0.1 - - [19/Oct/2018 11:18:40] 127.0.0.1:17777: Client closed connection
127.0.0.1 - - [19/Oct/2018 11:18:40] 127.0.0.1:17777: Closed target

The TCP server itself gets the connection from websockify but it is immediately closed by websockify.

Same thing happens with both Firefox and Chromium. I haven't tested other browsers.

[CendioOssman]

Actually, that log message shows that the connection is closed by the browser. Could it be that ws falls out of scope and is destroyed?

[1Hyena]

Yes, sorry if my description was ambiguous. It is apparent that the browser closes the connection indeed.

ws does not fall out of scope because I have the same browser code working when it connects to an older version of websockify ( the one you get from apt-get install on ubuntu based linuxes ). The same browser code also works when I use my own implementati of a websocket proxy. so I have figured that it is the latest websockify from this github repository that only suffers from this issue.

[CendioOssman]

Hmm... Are you trying to send text over that socket? We dropped support for text frames in the big cleanup.

Could you print the code and reason from the close in your close handler?

[1Hyena]

code: 1003
reason: Unsupported: Unknown opcode 0x01

btw, if support for text fames has been dropped then how should websockify exactly be used? I don't quite get it what it means to have dropped support for text frames.

[CendioOssman]

The WebSocket protocol is a bit of an oddball, so it has two modes of sending stuff. Either as text, or as raw data. But we need to proxy to normal TCP services which only sees data. So we naturally only use the raw data mode of WebSockets.

The older code did accept incoming text messages and mixed those in with any data messages. But it would only send data messages back, so we ended up in some kind of jumble. So now we keep things sane and only accept data messages.

From JavaScript that means you need to avoid sending text strings and use data types such as Uint8Array. Basically use the same data type as you are getting back in your message events.

[CendioOssman]

I've added 8eb5cb0 to make things a bit clearer at least.

Please have a look at your JavaScript code and adjust your send() calls and you should be fine.

[1Hyena]

@CendioOssman thanks for this fine feedback. Turns out that I indeed send data in text-mode since the send function gets a plain JS string for an argument. I will try sending explicitly in binary mode and will get back to you if it doesn't fix the issue, but I'm sure it does 😉