I've encountered something similar in the past, but it was around access logging. It all depends on what the load balancer can forward to tomcat in headers.
Port forwarding and resolving internally to the same domain externally seems to be how Tomcat wants to handle your issue. JMX M-Beans can offer some help in resolving request domains as well, but can get kind of ugly, and I'm not sure how portable that is. On 2/5/19, Johan Compagner <jcompag...@servoy.com> wrote: > On Tue, 5 Feb 2019 at 11:34, Jäkel, Guido <g.jae...@dnb.de> wrote: > >> >On 05/02/2019 08:23, Johan Compagner wrote: >> >> problem is that our customers are doing this. >> >> also they can have 1 tomcat with a few webapps that they want to map >> under >> >> different domains >> >> >> >> so that would mean for them starting 3 different tomcats under 3 >> different >> >> ports and configure all that >> >> thats not always something they want to do. >> >> So i guess the only way for me is to have some kind of setting (per >> context) >> > >> >They would be better configuring Tomcat with virtual hosts and having >> >three ROOT webapps. >> > >> >Mark >> >> Dear Johan, >> >> as Christopher and Mark wrote: If possible in any way, please avoid to >> handle it via rewriting on a reverse proxy and prefer to set up the >> Tomcat >> to serve the application on the same domain and context path as used >> "outside" in front of the proxy. >> >> If you real can't avoid, you have to do a forward rewriting of the used >> header (e.g. hostname) and/or URL pattern in the one hand, but also a >> complex backward rewriting of the answer! You have to back-rewrite parts >> of >> the answer header (Cookies, Locations, Links, ...) and the embedded URLs >> in >> the content of different MIME types (HTML, CSS, javascript, JSON, ...). >> As >> a consequence, you have either to forbid compression of the returned body >> or (even more complex) decompress/modify/recompress it on the fly. >> >> Sometimes, I simply can't avoid because we need to have an application >> available on two "addresses" while migration or something similar. And if >> the application itself can't be run in two instances I know no other way. >> But's it a real burden every time. >> >> >> > yeah i think we will document that if they want to have a reverse proxy in > front of it that maps it on root (very likely) > then they also should map the WAR on root in the tomcat behind that > And if they have multiply wars they should try to use virtual hosting on > tomcat as Mark described > As a last resort i think i will add a configuration param (per context) > where they can override it > > > -- > Johan Compagner > Servoy > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
