Xpra: Ticket #838: html5 client auto-connect

I think this used to be the case before, not 100% sure.

I would like to be able to do this:

xpra start --bind-tcp=0.0.0.0:10000 --start-child=xterm --html=on

Then just point my browser to it:

firefox http:127.0.0.1:10000

And be able to see the xterm without first going through the connect page.



Sun, 19 Apr 2015 13:29:30 GMT - Josh:

The correct behaviour should be as follows:

Load index.html -> auto connect -> if no hello packet received (or socket was closed before hello) redirect to connect.html


If you start Xpra using the following:

xpra start --bind-tcp=0.0.0.0:10000 --tcp-proxy=127.0.0.1:8080 websockify --web ./Xpra/trunk/html5/ 8080 localhost:10000

then it works correctly if you navigate to http://localhost:8080 - it will auto connect every time.

However if you navigate to http://localhost:10000 - sometimes it will auto connect and sometimes it will not.

If you start Xpra using the following:

xpra start --bind-tcp=0.0.0.0:10000 --start-child=xterm --html=on

and then navigate to http://localhost:10000 sometimes it will auto connect and sometimes it will not.


It seems as though if you connect to where websockify listens directly, it works fine. If you connect through Xpra's tcp proxy to websockify it does not work every time.

The client before r9050 shows the same behaviour.


Sun, 19 Apr 2015 13:32:50 GMT - Josh: attachment set

log of successful and failed auto connect


Sun, 19 Apr 2015 13:34:18 GMT - Antoine Martin: owner, status changed

Hah, ok. Then it's probably a bug on my side then. Taking the ticket back.


Mon, 20 Apr 2015 18:23:49 GMT - Antoine Martin: attachment set

chrome's network debug output


Mon, 20 Apr 2015 18:24:22 GMT - Antoine Martin: owner, status changed

Not sure what is going on here - it works, sometimes. Sometimes not:

2015-04-21 01:13:41,574 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54898))
2015-04-21 01:13:41,575 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54899))
2015-04-21 01:13:41,575 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54900))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54901))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54902))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903))
2015-04-21 01:13:41,579 client SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54898)) forwarded to proxy server 127.0.0.1:49657
2015-04-21 01:13:41,594 Connection lost
2015-04-21 01:13:41,594 xpra client disconnected.
2015-04-21 01:13:41,665 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54905))
2015-04-21 01:13:41,666 client SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54905)) forwarded to proxy server 127.0.0.1:49657
 32: 127.0.0.1: Plain non-SSL (ws://) WebSocket connection
 32: 127.0.0.1: Version hybi-13, base64: 'False'
 32: connecting to: 127.0.0.1:10000
2015-04-21 01:13:41,668 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54907))
2015-04-21 01:13:43,646 Connection lost
2015-04-21 01:13:51,576 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54899)))
2015-04-21 01:13:51,576 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54900)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54901)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54902)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903)))

All those connections are made by the browser to fetch different page assets (javascript includes, etc). The firebug-like chrome debugger shows that inflate.min.js is missing. Odd: chrome's network debug output

r9088 makes it easier to debug proxy + network issues, with this I can see lots of:

untilConcludes(<bound method SocketConnection.is_active of SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54929))>, <built-in method recv of _socket.socket object at 0x44ec810>, (65536,), {}) timed out

Maybe we need to reset the sockets to blocking mode instead of timing out? (it should still work though...)

@joshiggins: any thoughts?


Mon, 20 Apr 2015 19:10:17 GMT - Josh:

The inflate.min.js is minified and chrome is requesting a source map inflate.min.js.map to show the original code in the debugger, but it's not there. Doesn't seem to request it unless you open the debugger tools. So that one is expected.

I'm not sure what to make of the rest.

2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903)))

I assume that for these, Xpra was waiting for a client handshake but they probably should have gone to websockify?


Tue, 21 Apr 2015 16:18:06 GMT - Antoine Martin:

Minor fixes that could help in r9104 + r9105. r9096 makes debugging the proxy stuff a little easier.

I am still seeing failures in about 50% of the time. @joshiggins: how do I enable debugging of the html5 code to see where it is at? (especially the page loading, startup / connect code)


Tue, 21 Apr 2015 16:27:09 GMT - Josh:

@antoine, with r9106 you can add index.html?debug=true to avoid the connect page redirect. The web console should show the usual messages.

It will say received an 'open' packet when the websocket is opened.


Tue, 21 Apr 2015 16:59:30 GMT - Antoine Martin: owner, status changed

@joshiggins: thanks, that's very useful.

It seems that whenever it fails, it gets stuck after sending the hello. At least now I know where to look.


Thu, 23 Apr 2015 14:24:26 GMT - Antoine Martin:

Not had time to look into it, but with the latest trunk I get:

disconnect: invalid packet format, not an xpra client?

Is it just me?


Thu, 23 Apr 2015 14:31:22 GMT - Josh:

Not seeing this on my end with latest trunk.....


Fri, 24 Apr 2015 13:03:57 GMT - Antoine Martin:

Not seeing this on my end with latest trunk.....


Never mind, that was me getting it completely wrong and hitting the wrong server!


Inspecting the packets over the "wire", I can see that when things fail, they fail just after the request to "switch protocols" from the websockify server:

T 127.0.0.1:36534 -> 127.0.0.1:49087 [AP]
  HTTP/1.1 101 Switching Protocols..Upgrade: websocket..Connection: Upgrade..Sec-WebSocket-Accept: 63KVuzlVx/3Lj54jOsM1X6ef+hk=..Sec-WebSocket-Protocol:
  binary....

Which we correctly forward to the client.

The client then responds with some binary data, which we forward to the websockify server... except when the bug occurs: it looks like the data is sent to the xpra server, but never received or forwarded to the websockify server.


Mon, 27 Apr 2015 04:46:00 GMT - Antoine Martin: attachment set

adds debugging to the low level network code


Mon, 27 Apr 2015 07:32:17 GMT - Antoine Martin: attachment set

a possible fix - not pretty


Mon, 27 Apr 2015 07:33:57 GMT - Antoine Martin:

The bug has been identified and also affects the proxy server (#426).

The fix above is probably correct, I just wished it wasn't so convoluted - tying the steal_connection code with connection.set_active and things that should be hidden away..


Mon, 27 Apr 2015 09:04:01 GMT - Antoine Martin:

Finally fixed in r9160!

I think that the proxy server code is safe because we do not expect any packets after the hello until we have replied with our own hello response. This is a bit big to backport, will need to think about it.


Tue, 28 Apr 2015 04:09:52 GMT - Antoine Martin: status changed; resolution set

Backport in r9173. (not all that big, tested ok)


Sat, 23 Jan 2021 05:07:30 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/838