xpra icon
Bug tracker and wiki

#1714 closed enhancement (fixed)

Create command line argument for web path and web socket path

Reported by: esarmien Owned by: esarmien
Priority: minor Milestone: 2.2
Component: server Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

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.

Change History (7)

comment:1 Changed 11 months ago by Antoine Martin

Owner: changed from Antoine Martin to esarmien

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?

comment:2 Changed 11 months ago by 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

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 11 months ago by Antoine Martin

Description: modified (diff)

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.

comment:4 Changed 11 months ago by 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!

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 11 months ago by 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:

  • with apache: use URL re-write in the proxy
  • host the static part of the xpra html5 client at the root URL: all users connect to "/index.html?path=theirownpath" - you just need a dummy xpra server answering to all root urls to serve the static content (and since this server would only serve html content and not handle websocket connections, it does not need to be an xpra server at all, any http server will do)

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.

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 10 months ago by 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

comment:7 Changed 10 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.