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