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.
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.
log of successful and failed auto connect
Hah, ok. Then it's probably a bug on my side then. Taking the ticket back.
chrome's network debug output
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:
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?
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?
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)
@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.
@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.
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?
Not seeing this on my end with latest trunk.....
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.
adds debugging to the low level network code
a possible fix - not pretty
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..
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.
Backport in r9173. (not all that big, tested ok)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/838