On 13/06/2016 15:32, Xavier Dury wrote: > 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/
Tomcat supports virtual hosts as well. Just configure two virtual hosts with separate a docBase and a ROOT app each. You'll need to make sure the proxy passes on the host header. >> 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? Anything is possible. How simple would the code be? I don't know. How fragile would such a solution be? I don't know. What would the performance impacts of such a solution be? I don't know. How long would it take to implement and test? Several orders of magnitude more than setting up a couple of virtual hosts in Tomcat and configuring them appropriately. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
