From users-return-267500-archive-asf-public=cust-asf.ponee.io@tomcat.apache.org Tue May 7 12:36:46 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6AAC418064C for ; Tue, 7 May 2019 14:36:46 +0200 (CEST) Received: (qmail 72950 invoked by uid 500); 7 May 2019 12:36:43 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 72939 invoked by uid 99); 7 May 2019 12:36:43 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 May 2019 12:36:43 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id EEDB61810BF for ; Tue, 7 May 2019 12:36:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 9I2WLqwUF1jF for ; Tue, 7 May 2019 12:36:40 +0000 (UTC) Received: from thor.wissensbank.com (thor.wissensbank.com [81.169.250.120]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 82A6360E56 for ; Tue, 7 May 2019 12:36:40 +0000 (UTC) Received: from thor.wissensbank.com (localhost [127.0.0.1]) by thor.wissensbank.com (Postfix) with ESMTP id 999141E100064 for ; Tue, 7 May 2019 14:36:39 +0200 (CEST) Received: by thor.wissensbank.com (Postfix, from userid 500) id 8397B1E10010F; Tue, 7 May 2019 14:36:39 +0200 (CEST) Received: from [192.168.245.152] (unknown [188.130.198.139]) (Authenticated sender: andre.warnier@ice-sa.com) by thor.wissensbank.com (Postfix) with ESMTPA id DD9D51E100064 for ; Tue, 7 May 2019 14:36:38 +0200 (CEST) Subject: Re: Apache httpd / tomcat AJP connector(s?) To: users@tomcat.apache.org References: <5CC03339.3030402@ice-sa.com> <84e74778-e9c0-4388-f2a7-643275f10046@apache.org> From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat=29?= Message-ID: <5CD17C11.30309@ice-sa.com> Date: Tue, 7 May 2019 14:37:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <84e74778-e9c0-4388-f2a7-643275f10046@apache.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 , 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 ). 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-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org