> On 13/06/2016 14:23, Xavier Dury wrote:
> > Hi,
> >
> > The recommended approach when using a proxy in front of tomcat is to have
> > the same context path
> > on both sides like this:
> >
> > http://mycompany.com/myapp --> http://myinternalserver.lan:8080/myapp
> >
> > Having different context paths like this:
> >
> > http://mycompany.com/mypublicapp -->
> > http://myinternalserver.lan:8080/myprivateapp
> >
> > would need to rewrite urls in the generated html with something like
> > mod_proxy_html:
> >
> > /myprivateapp/* would need to be rewritten as /mypublicapp/*.
> >
> > Instead of using mod_proxy_html, is it possible to have a valve that would
> > take
> > care of this by letting the proxy send the correct contextPath in a
> > request header (RequestHeader set X-Forward-ContextPath "mypublicapp")
> > which would alter the
> > behaviour of request.getContextPath(), response.sendRedirect(), etc.?
> >
> > So, if you are using ${pageContext.request.contextPath} in your
> > application, it would give the
> > correct context path for the external world and there would be no need to
> > rewrite urls.
> >
> > Or is it a bad idea?
> >
> > Proxies can already send the remote server, ip address, port to tomcat...
> > so why not the context path?
>
> Mu gut reaction is that such a valve would be much more complex to
> implement that it would be to simply rename the WAR on the Tomcat side
> so the paths matched.
What about the following scenario (using only one tomcat instance for two
virtual hosts):
http://www.mysite.com/ -->
http://myinternalserver.lan:8080/www/http://admin.mysite.com/ -->
http://myinternalserver.lan:8080/admin/
> The Tomcat internals assume that the context path associated with the
> request is consistent with the context path associated with the web
> application processing the request. I don't know if anything would break
> if that assumption was not valid.
So a valve would not be able to override that behavior?
Xavier
