Hi.
On 26.04.2019 18:16, Mark Thomas wrote:
On 24/04/2019 10:58, André Warnier (tomcat) wrote:
Hi.
This is somewhat of an arcane question and somewhat straddling httpd and
tomcat, so if I'm on the wrong list for this, just let me know.
Here is fine. We can always move the thread if necessary.
The question is : is there any particular reason why the combination
mod_proxy + mod_proxy_ajp (in httpd), does not seem to follow the
ProxyPreserveHost directive, when proxying something from httpd to tomcat ?
None that I am aware of.
I've complete a quick test with httpd 2.4.34 and Tomcat 9.0.x and I see
the host header is passed via AJP as expected.
I suggest wireshark to look at what is on the wire.
I haven't done a wireshark trace yet.
But as a cheap approximation for now, I tried to use the (tomcat) Access Log to see what
was going on, and there I hit another (but I believe related) issue :
According to :
http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve
some patterns available are :
- %p - Local port on which this request was received.
and
- %{xxx}p write local (server) port (xxx==local) or remote (client) port
(xxx=remote)
So if I understand this right, "%{local}p" should print the same as "%p", and both should
be "the local port on which this request was received".
However,
- in our tomcat 8.5 setup, there is /only/ the AJP Connector enabled, on port 8009. So
this would be the only local port on which a request /can/ be received. (There is also a
single <Host>, the default "localhost").
- correspondingly, in the front-end Apache httpd, some requests are proxied to tomcat, via
a directive like
Proxypass /zzz/ ajp://locahost:8009/zzz/
(and no other Proxy directives to any other port than 8009)
- in httpd, there is also a directive which forces the "Host" header of the proxied
requests, to be (edited)
SetEnvIf Request_URI "^/zzz/" isMyReq=yes
RequestHeader set Host "www.myhost.com:8083" env=isMyReq
(*)(**)
(So the net result is, that any request coming in for "^/zzz/", gets proxied to
localhost's Tomcat's AJP port 8009, but with a "Host" header which mentions a different
hostname:port)
and the surprising thing is :
In the tomcat access log, both "%p" and "%{local}p" print "8083" as the port.
(and I have not found a way to print "8009", which is the /real/ local port on which this
request is received, which can only be "8009")
So it looks as if, in any case that I have tested, the "port" part of the "Host" header of
the request received by tomcat, *overrides* the "local port" part of both "%p" and
"%{local}p", which does not seem to be the original intention (otherwise, why have
separate "%p" and "%{local}p" format specifiers ?)
It also seems that there is no format pattern available which prints a clue about the real
Connector/port on which the request was received. (That's more of an enhancement request,
but this is really missing (for debugging) in some complicated configuration/usage scenarios).
Additional note/disclaimer : I apologise for not having had the occasion so far to
configure and perform some real exhaustive test scenarios (in this case I am working on
customer systems, and they also want to use them sometimes). I have also experienced some
similar phenomenons (or confusion) like the above regarding the "hostname" part of the
requests (and for example the "proxyName/proxyPort" attributes of the Connector, and/or
the "Alias" tag inside the <Host>). It could be just the documentation that is somewhat
confusing; it feels like some things are a bit "out of sync", but it is hard to tell if
one should start from the documentation and check if the code matches it, or in reverse.
(*) there are more sets like that one, with different host:port combinations.
(**) the reason for this complicated setup, is that there are 2 front-end proxies in
sequence before tomcat (plus a tomcat application which generates its own self-referencing
links). Plus some clients which access the application through SSH tunnels on different ports.
And, we need tomcat to return links which reference the *first* of the front-line proxies
(which is the "public" host for the application), but also the port to which the client
issued its own original request.
So it makes for some interesting URL-rewriting and Proxy rules, of which the above is only
a small sample.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
