xpra icon
Bug tracker and wiki

Changes between Initial Version and Version 3 of Ticket #1714


Ignore:
Timestamp:
12/04/17 17:16:41 (3 years ago)
Author:
Antoine Martin
Comment:

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.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1714

    • Property Owner changed from Antoine Martin to esarmien
  • Ticket #1714 – Description

    initial v3  
    11Antoine,
    22
    3 In this ticket: https://xpra.org/trac/ticket/1510, you specified how someone could change the websocket path by editing index.html and changing the parameters of the XpraClient object.
     3In this ticket: #1510, you specified how someone could change the websocket path by editing index.html and changing the parameters of the XpraClient object.
    44
    5 At Harvard, we want to serve XPRA-wrapped applications from a relative URL http://sid.aws.hmdc.harvard.edu/xpra-application-1234
     5At Harvard, we want to serve XPRA-wrapped applications from a relative URL, ie: {{{http://sid.aws.hmdc.harvard.edu/xpra-application-1234}}}
    66
    77Two problems with this