Re: [Exist-open] reverse proxying eXist on a hidden port: apache configuration

[Ron V. d. B. <ron...@ka...>]

Hi Dannes,

On 11/04/2012 23:25, Dannes Wessels wrote:
>
> the basis of the jnlp problem is that the JNLP file needs to contain 
> an absolute path to where the document, and thus the resources of the 
> application are to be found. For the webstart client it must match the 
> URL on the public http port.... unfortunately the jnlp code does not 
> know anything about the external port, only the internal one.
>
> The embedded URL is not usable for the outside world............ 
> probably is the same true for the xmlrpc-url in the JNLP file.
>
>

True.

> So what are the options?
>
> (1) download the JNLP file, modify it manually and provide it to your 
> users [most control!]

This indeed isn't much more useful than connecting via a shipped eXist 
Java client and hoping it is compatible with the version of the eXist db 
it is connecting to.

> (2) we can change the jnlp code..... a reverse proxy typically adds an 
> extra header representing the external URL. if the header is 
> available, we could use this information in stead.
>

Hmm, I think switching 'on' the mod_proxy ProxyPreserveHost setting 
comes close: this way, the JNLP file will see the host name of the 
original request (hence, the 'public' request). For example, if 
<http://mydomain/apps/exist/webstart/exist.jnlp> is reverse proxied to 
<http://localhost:8082/exist/webstart/exist.jnlp> with the proxy 
settings I discussed in my previous message, eXist (and the JNLP file) 
will see this URL: <http://mydomain/exist/webstart/exist.jnlp>.

Note, however, the subtle difference: the '/apps/' part starting the 
original request path has been filtered out by the proxy handling, so 
eXist doesn't see this. I doubt if it is within reach of eXist (or any 
reverse proxied app) to see the actual URL: listing all headers with 
following XQuery script:

   <headers url="{request:get-url()}">{
     for $a in request:get-header-names()
     return<header name="{$a}">{request:get-header($a)}</header>
   }</headers>

... in an eXide app running in above proxied app returns this:

<headers url="http://localhost:8082/exist/eXide/execute">
   <header name="host">localhost:8082</header>
   <header name="user-agent">Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0</header>
   <header name="accept">application/xml, text/xml, */*; q=0.01</header>
   <header name="accept-language">en-gb,en;q=0.5</header>
   <header name="accept-encoding">gzip, deflate</header>
   <header name="content-type">application/x-www-form-urlencoded; charset=UTF-8</header>
   <header name="x-requested-with">XMLHttpRequest</header>
   <header name="referer">http://mydomain/apps/exist/eXide/index.html</header>
   <header name="cookie">JSESSIONID=01AB1164A76030B69473074CBDEAE44E; PIWIK_SESSID=add6c3b38de94e2481b1335875777e1b; JSESSIONID=01AB1164A76030B69473074CBDEAE44E</header>
   <header name="pragma">no-cache</header>
   <header name="cache-control">no-cache</header>
   <header name="via">1.1 mydomain</header>
   <header name="x-forwarded-for">81.241.230.23</header>
   <header name="x-forwarded-host">mydomain</header>
   <header name="x-forwarded-server">mydomain</header>
   <header name="connection">Keep-Alive</header>
   <header name="content-length">285</header>
</headers>

Hence, the only place where the '/apps/' prefix shows up is the 
'referer' header, which is probably only there because of the execution 
via eXide.

Otherwise, the JNLP webstart client works fine without the '/apps/' 
prefix, i.e. if I proxy the entire webspace. So I guess there are 2 
options that don't need any JNLP tinkering:
     1) deal with that missing '/apps/' prefix in the Apache 
configuration file, so that requests containing 'webstart' or 'xmlrpc' 
are proxied even without the '/apps/' prefix
         (that's the workaround I explained in my previous message)
     2) make my life easier, and introduce a physical '/app/' folder in 
the proxied Tomcat app, so that a request for 
<http://mydomain/apps/exist/> can be reverse proxied to 
<http://localhost:8082/apps/exist/>.
         I'm still looking on how to achieve this.

So, in summary: probably, the remaining problem (preserving the 
connection between the 'virtual' path prefix ('/apps/') I use in the 
original URL, and the URL the proxied server sees) is a complication 
inherent to the way I'm setting up this particular reverse proxying 
scenario. OTOH, I guess it could make sense to extend the documentation 
with a scenario for reverse proxying eXist on a non-public port (which 
seems a realistic scenario to me), without having to change the JNLP 
code. (Though I'm far from a webadmin expert and all of my 'knowledge' 
stems from a couple of weeks experience trying to get my setup working, 
and if above insights make sense, I wouldn't mind volunteering for doing 
this.)

Kind regards,

Ron