James Casbon wrote:
Not sure I understand - you mean that the base url is technically correct but the proxy introduces the error? What we need is the ability to set the base url for this kind of situation.
The URL scheme between Apache and Galaxy is http. Between Apache and the end user it can be anything (in your case, https). Galaxy only knows which scheme it's using with its immediate upstream. I'll go ahead and commit my fix so that Galaxy generates the URL correctly. This should solve any future problems or integration with other external sources. But it won't fix UCSC, which I'll explain in a moment. To generate proper 'https' URLs, inside the SSL VirtualHost in which you proxy Galaxy you'd need to add this: RequestHeader set X-URL-SCHEME https Galaxy will then check the X-URL-SCHEME header and override the previously defined scheme (http) accordingly. However, UCSC cannot read data over https[1], so fixing the URL will not actually help. However, you can serve UCSC data over http via a hackish workaround: 1. Don't set X-URL-SCHEME as described above. Galaxy will continue to generate (incorrect) 'http' links. 2. In the non-SSL VirtualHost for galaxy.example.com, set up a proxy similar to how you did in the SSL VirtualHost, but only for /root/display_as. You'll want to deny connections from everywhere but UCSC: <VirtualHost *:80> ... standard stuff ... Order deny,allow Deny from all Allow from hgw1.cse.ucsc.edu Allow from hgw2.cse.ucsc.edu Allow from hgw3.cse.ucsc.edu Allow from hgw4.cse.ucsc.edu Allow from hgw5.cse.ucsc.edu Allow from hgw6.cse.ucsc.edu Allow from hgw7.cse.ucsc.edu Allow from hgw8.cse.ucsc.edu RewriteEngine on RewriteRule ^(/root/display_as.*) http://localhost:8192$1 [P,L] RewriteRule ^(.*) - [F] </VirtualHost> Authentication configuration is not necessary since you are only allowing through UCSC, unauthenticated. Everything else in that VirtualHost will return 403 Forbidden. [1] http://www.soe.ucsc.edu/pipermail/genome/2008-April/015997.html --nate