See #473. At the moment, one has to choose port numbers and point xpra to websockify and tell websockify to point back to xpra. This is all tedious and error prone.
Instead, let's add a --html=on
switch which will do everything in one.
Done in r7743. Now I can start an xpra server like so:
xpra start :10 --start-child=xterm --bind-tcp=0.0.0.0:10000 --html=on
Then just point my browser to the xpra port and get the html login page:
xdg-open http://127.0.0.1:10000/
afarr: over to you. Note: this ticket is just for recording this new command line feature. The html5 client issues belong in #473.
Tested against a Fedora 20 r7840:
Entering --html=on
in the CLI when calling the normal Xpra start commands produces this output:
WebSocket server settings: - Listen on 127.0.0.1:39091 - Flash security policy server - Web server. Web root: /usr/share/xpra/www - No SSL/TLS support (no cert file) - proxying from 127.0.0.1:39091 to 127.0.0.1:1200
And then upon navigating to http://10.0.32.52:1200 (IP of the machine) I am greeted by the HTML login page. It looks like --html=on
is working. Re-starting the server with --html=off
and refreshing the webpage throws an error telling me disconnect: invalid packet format, not an xpra client?
indicating HTML is no longer running.
If you need any more testing pass this ticket my way.
Closing.
I am unable to get the html5 client to work or I am not understanding the directions. I am stuck on "disconnect: invalid packet format, not an xpra client?" and cannot proceed any further.
here is some output from the server
2014-10-13 13:15:23,238 New connection received: SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50742)) 2014-10-13 13:15:23,240 Disconnecting client Protocol(SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50742))): invalid packet format, not an xpra client? 2014-10-13 13:15:23,446 New connection received: SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50743)) 2014-10-13 13:15:23,447 Disconnecting client Protocol(SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50743))): invalid packet format, not an xpra client? 2014-10-13 13:15:23,449 New connection received: SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50744)) 2014-10-13 13:15:23,450 New connection received: SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50745)) 2014-10-13 13:15:23,452 Disconnecting client Protocol(SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50744))): invalid packet format, not an xpra client? 2014-10-13 13:15:23,452 Disconnecting client Protocol(SocketConnection(('10.1.32.77', 1200) - ('10.1.32.130', 50745))): invalid packet format, not an xpra client?
What command have you used to start the server? What version, etc Where do you point the browser to?
using trunk from 10/13/14 Fedora 20
xpra start :10 --start-child=xterm --bind-tcp=0.0.0.0:1200 --html=on
then I navigate to http://machinesip:1200 using Chrome on windows.
Do you have websockify installed?
What's in your server log? (in full)
Another ticket that keeps on giving!
This code was added in r7743 (as per above), but got moved in r7928 for #711 - which broke it. The fix was not completely straightforward, but the code is better for it I think: if r7939 for you, please re-assign to afarr to make sure I haven't broken anything else (again), as this now touches shadow servers too...
aradtech / afarr: if this works for you (no need to re-test everything), please close this ticket.
Launching and connecting with a browser to the server works as expected. Pretty cool, actually.
Closing.
This broke because of #638 in r8303, fixed in r8516. Also needed r8517 to re-set the tcp_proxy option.
See also #838.
Re-tested, osx & windows... still looks good.
Had one instance with win32 client that wouldn't give keyboard focus to the xterm, but saw nothing in logs and couldn't reproduce (and not for lack of trying).
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/689