tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Apache httpd / tomcat AJP connector(s?)
Date Tue, 07 May 2019 12:37:37 GMT

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 :
some patterns available are :
- %p - Local port on which this request was received.
- %{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".

- 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 "" 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 

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:
For additional commands, e-mail:

View raw message