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. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
