Xpra: Ticket #1714: Create command line argument for web path and web socket path

Antoine,

In this ticket: #1510, you specified how someone could change the websocket path by editing index.html and changing the parameters of the XpraClient? object.

At Harvard, we want to serve XPRA-wrapped applications from a relative URL, ie: http://sid.aws.hmdc.harvard.edu/xpra-application-1234

Two problems with this 1) I need to use sed in all of our containers to edit index.html to set the appropriate web socket path to the relative url as in the above example 'xpra-application-1234', it would be great if this was a command line argument.

2) I have to rewrite the requests to XPRA because the path we want is a relative path, not the root path. Using proxy rewrites is OK but I would prefer not to. It would be great if you could add another argument called something like '--web-path', which would specify that XPRA static html files are being served from a relative path, rather than /. Currently I need to re-write all HTTP requests to /xpra-application-1234 for / in order for the static HTML to be served properly.

In most cases, 1 && 2 would end up being the same.



Mon, 04 Dec 2017 16:23:56 GMT - Antoine Martin: owner changed

I need to use sed in all of our containers to edit index.html to set the appropriate web socket path to the relative url as in the above example 'xpra-application-1234'

Can you show us an example of what that change looks like?

I have to rewrite the requests to XPRA because the path we want is a relative path, not the root path

Is this for all the file resources only? (icons, javascript files, etc) Can't we just use a relative URL for all of these and solve this particular problem?


Mon, 04 Dec 2017 16:26:28 GMT - esarmien:

Hi Antoine,

Yes. We can use a relative URL for all those and solve the second problem.

As for the first problem,

client.host = "hostname.com;
client.port = 443;
client.ssl = true;
client.path = "xpra/somepath"

This was the example you gave in the ticket that I linked, which I use. I change client.path to the relative path of the url which hosts the XPRA-wrapped application, for example

I change

client.path = "xpra/somepath"

to

client.path = "xpra-application-1234"

for websockets to work.

If there was a command line argument which could change this value (it could actually just be one argument which changes both this value and the relative web path as you mentioned), it would be great.

Best, Evan


Mon, 04 Dec 2017 17:16:41 GMT - Antoine Martin: description changed

We can use a relative URL for all those and solve the second problem.

Having looked at it, the only non-relative URL I could find was the favicon (changed in r17566). This would not have caused any problems on its own. Is there anything else that requires patching?

I change ... for websockets to work.

So you must have a proxy forwarding requests to xpra server instances sitting behind it, right? Be aware that this can cause performance issues.

Rather than adding yet-another command line argument (and man pages, command line parsing, etc), can't we just detect the URL where xpra is installed at runtime? That would be easier and would not require any configuration. This could be done even more easily with apache requestheader and r17567: just pass an extra request attribute of path=thepathyouwant to the client's index page and it will use that.


Mon, 04 Dec 2017 18:33:34 GMT - esarmien:

Having looked at it, the only non-relative URL I could find was the favicon (changed in r17566). This would not have caused any problems on its own. Is there anything else that requires patching?

There only issue here is proxying. XPRA being served at the relative path will proxy a request to XPRA with that relative path, so, for example, if XPRA is being served at /xpra-application-1, then the XPRA web server will receive an HTTP GET for /xpra-application-1, which will result in a 404 because the path is served at the root. It would be great if the actual path ere could be configurable.

This could be done even more easily with ​apache requestheader and r17567: just pass an extra request attribute of path=thepathyouwant to the client's index page and it will use that.

Appending query strings to the URL to specify web socket path is totally fine with me. Yes, I am aware that proxying will cause some performance reduction but we need to tie this into Harvard CAS/SAML authentication and the proxy I wrote does this. So far I've been using it this way and it performs pretty well!


Tue, 05 Dec 2017 12:18:18 GMT - Antoine Martin:

for example, if XPRA is being served at /xpra-application-1, then the XPRA web server will receive an HTTP GET for /xpra-application-1, which will result in a 404 because the path is served at the root.

2 easy solutions to this:

Changing xpra would be very hard: the urls are static and the HTML pages are not dynamically generated either. Looks like the wrong place to come up with a fix.


Thu, 07 Dec 2017 15:24:07 GMT - esarmien:

OK Antoine, that sounds good. I see that you committed the extra query string to trunk. Any idea when this will be merged into a stable release?

Thanks again Evan


Thu, 07 Dec 2017 19:00:44 GMT - Antoine Martin: status changed; resolution set

2.2 will be released within a few days, and includes this change.

I am closing this ticket as "fixed" because this should be enough for your needs. Feel free to re-open if I've missed something.


Sat, 23 Jan 2021 05:31:49 GMT - migration script:

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