html5 client auto-connect

[totaam]

Issue migrated from trac ticket # 838

component: html5 | priority: minor | resolution: fixed

2015-04-19 08:09:45: antoine created the issue

---

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.

[totaam]

2015-04-19 14:29:31: joshiggins commented

---

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.

[totaam]

2015-04-19 14:32:51: joshiggins uploaded file autoconnectlog.txt (24.8 KiB)

log of successful and failed auto connect

[totaam]

2015-04-19 14:34:18: antoine changed status from new to assigned

[totaam]

2015-04-19 14:34:18: antoine changed owner from joshiggins to antoine

[totaam]

2015-04-19 14:34:18: antoine commented

---

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

[totaam]

2015-04-20 19:23:49: antoine uploaded file chrome-network-debug.png (63.6 KiB)

chrome's network debug output

[totaam]

2015-04-20 19:24:22: antoine changed status from assigned to new

[totaam]

2015-04-20 19:24:22: antoine changed owner from antoine to joshiggins

[totaam]

2015-04-20 19:24:22: antoine commented

---

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:
[[Image(chrome-network-debug.png)]]

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?

[totaam]

2015-04-20 20:10:18: joshiggins commented

---

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?

[totaam]

2015-04-21 17:18:07: antoine commented

---

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)

[totaam]

2015-04-21 17:27:09: joshiggins commented

---

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

[totaam]

2015-04-21 17:59:31: antoine changed status from new to assigned

[totaam]

2015-04-21 17:59:31: antoine changed owner from joshiggins to antoine

[totaam]

2015-04-21 17:59:31: antoine commented

---

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

[totaam]

2015-04-23 15:24:26: antoine commented

---

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?

[totaam]

2015-04-23 15:31:22: joshiggins commented

---

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

[totaam]

2015-04-24 14:03:57: antoine commented

---

Not seeing this on my end with latest trunk.....
[[BR]]
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.

[totaam]

2015-04-27 05:46:01: antoine uploaded file proxy-network-debugging.patch (3.2 KiB)

adds debugging to the low level network code

[totaam]

2015-04-27 08:32:17: antoine uploaded file fix-steal-connection-race.patch (5.1 KiB)

a possible fix - not pretty

[totaam]

2015-04-27 08:33:57: antoine commented

---

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

[totaam]

2015-04-27 10:04:02: antoine commented

---

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.

[totaam]

2015-04-28 05:09:53: antoine changed status from assigned to closed

[totaam]

2015-04-28 05:09:53: antoine set resolution to fixed

[totaam]

2015-04-28 05:09:53: antoine commented

---

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