I don't know whether this is on the mod_proxy_ajp side or the tomcat side, so ... host: linux (CentOS, aka RHEL, 4 with all current updates) browser: firefox 1.0.7 httpd: 2.1.7, built from source tomcat: 5.0.28, binary distribution append to /etc/hosts: 127.0.0.1 localhost tomcat append to httpd.conf: <VirtualHost *> ServerName tomcat #ProxyPass / ajp://localhost:8009/ ProxyPass / http://localhost:8080/ #ProxyPassReverse / ajp://localhost:8009/ ProxyPassReverse / http://localhost:8080/ </VirtualHost> No other changes from a default installation of the two servers. The first problem is that if you simply browse to http://tomcat and click on admin, it works with HTTP, but not with AJP. To illustrate, let's compare the differences with wget: AJP: $ wget http://tomcat/admin --01:06:56-- http://tomcat/admin => `admin' Resolving tomcat... 127.0.0.1 Connecting to tomcat|127.0.0.1|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://tomcat/admin/ [following] --01:06:56-- https://tomcat/admin/ => `index.html' Connecting to tomcat|127.0.0.1|:443... failed: Connection refused. Resolving tomcat... 127.0.0.1 Connecting to tomcat|127.0.0.1|:443... failed: Connection refused. HTTP: $ wget http://tomcat/admin --01:09:20-- http://tomcat/admin => `admin' Resolving tomcat... 127.0.0.1 Connecting to tomcat|127.0.0.1|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://tomcat/admin/ [following] --01:09:20-- http://tomcat/admin/ => `index.html' Connecting to tomcat|127.0.0.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2,622 (2.6K) [text/html] 100%[====================================>] 2,622 --.--K/s 01:09:20 (53.20 MB/s) - `index.html' saved [2622/2622] Note that the 302 redirects from HTTP to HTTPS in the AJP case, but not in the HTTP case. OK, so let's bypass the 302 and go directly to http://tomcat/admin/. The initial GET works with either protocol, e.g., with AJP: # wget http://tomcat/admin/ --01:10:06-- http://tomcat/admin/ => `index.html.1' Resolving tomcat... 127.0.0.1 Connecting to tomcat|127.0.0.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2,615 (2.6K) [text/html 100%[====================================>] 2,615 --.--K/s 01:10:06 (95.92 MB/s) - `index.html.1' saved [2615/2615] However, the resources referenced on the page are only fetched when using HTTP, not AJP. The difference is readily apparent. The images, stylesheets, etc., are served up with HTTP, but not with AJP.
If you bring up the same stock configurations described above, you can also reproduce the redirect to HTTPS problem by accessing http://tomcat/tomcat-docs.
I can reproduce the problem with 5.5.12 (and httpd 2.0.8) as well, so since from the lack of response no one in tomcat-dev appears to care about problems with 5.0.x, I'm modifying the record to show that it effects the current development branch, too.
(In reply to comment #2) > ... httpd 2.0.8 ... Er, make that 2.1.8, i.e., the latest available code.
(In reply to comment #2) > I can reproduce the problem with 5.5.12 (and httpd 2.0.8) as well, so since > from the lack of response no one in tomcat-dev appears to care about problems > with 5.0.x, I'm modifying the record to show that it effects the current > development branch, too. It seems that the problem is that mod_proxy_ajp isn't playing nice with mod_ssl (so that this is really a Httpd bug). Even when the connection isn't HTTPS, mod_proxy_ajp is sending (empty) SSL attributes like cipher, client- cert, session-id. This causes Tomcat to believe that the request was recieved on HTTPS, so it redirects accordingly. Below is a dump of the Request message that Tomcat recieves from Httpd: FINE: 12 34 00 6b 02 02 00 08 48 54 54 50 2f 31 2e 31 | .4.k....HTTP/1.1 FINE: 00 00 0c 2f 74 6f 6d 63 61 74 2d 64 6f 63 73 00 | .../tomcat-docs. FINE: 00 09 31 32 37 2e 30 2e 30 2e 31 00 ff ff 00 07 | ..127.0.0.1.??.. FINE: 68 6f 75 73 74 6f 6e 00 22 b8 00 00 02 a0 0b 00 | houston."?...?.. FINE: 0c 68 6f 75 73 74 6f 6e 3a 38 38 38 38 00 00 0c | .houston:8888... FINE: 4d 61 78 2d 46 6f 72 77 61 72 64 73 00 00 02 31 | Max-Forwards...1 FINE: 30 00 07 00 00 00 08 00 00 00 09 00 00 00 ff | 0.............?
Now that William Barker has assessed the defect locale, try reassigning to Apache httpd-2.0 product.
Created attachment 16617 [details] Patch against trunk Thanks to all for the analysis data. The attached patch against trunk should fix this. Can you please give it a try and give feedback.
Created attachment 16619 [details] Patch against Tomcat 5.5.9 After doing some further tests and further analysis I must revert my earlier assumption that this is a httpd bug. It rather seems that org.apache.ajp.RequestHandler does not honour the isSSL bit inside an ajp message correctly. Attached is a patch against Tomcat 5.5.9 that should fix this.
Hi, I must dissagree with you. The bug has nothing to do with Tomcat. Tomcat works pretty well with mod_jk w or w/o SSL. The error is obviously in mod_proxy_ajp.
Mladen is insisting that the problem is with mod_proxy_ajp, so he'll veto the patch. Unfortunately, he's quite busy right now, so more comments later. It also seems to me that it is a mod_proxy_ajp bug if it sends bogus HTTPS related headers if this isn't actually using HTTPS.
(In reply to comment #7) > Created an attachment (id=16619) [edit] > Patch against Tomcat 5.5.9 > After doing some further tests and further analysis I must revert my earlier > assumption that this is a httpd bug. It rather seems that > org.apache.ajp.RequestHandler does not honour the isSSL bit inside an ajp > message correctly. Attached is a patch against Tomcat 5.5.9 that should fix > this. The first patch of mod_proxy_ajp is sub-optimal, but will work. It would be better if mod_proxy_ajp honored the is_ssl flag and didn't bother to check the SSL attributes unless it was set. Your patch of Tomcat isn't even worth vetoing, since the patched class doesn't exist in 5.5.x, and is deprecated in 4.1.x.
Play watch the bouncing bug ;-).
Created attachment 16620 [details] Fix for mod_proxy_ajp's SSL attributes This fixes mod_proxy_ajp handling of SSL attributes. Not only does it stop it from sending garbage to Tomcat, but it doesn't even bother with the lookup unless the request came in on SSL. And, as a bonus feature, it even gets the key-size working again. Someday, mod_proxy_ajp may be almost as good as mod_jk ;-).
Apart from a few minor style issues the patch looks good to me. Thanks. It removes the problem I saw with my first version of the patch which did not fix it correctly. What still worries me a little bit is the comment above the key_size block, which says "added support only in ajp14 mode". Maybe I am just misreading this comment, but could someone of the AJP gurus confirm that this attribute is also valid in AJP13?
(In reply to comment #13) > misreading this comment, but could someone of the AJP gurus confirm that this > attribute is also valid in AJP13? All current release versions of Tomcat support it, and any older ones will ignore an attribute that they don't recognize.
Committed a style adjusted variant to trunk (r307195) http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/modules/proxy/ajp_header.c?rev=307195&r1=232247&r2=307195 and to 2.2.x branch (r307196) http://svn.apache.org/viewcvs.cgi/httpd/httpd/branches/2.2.x/modules/proxy/ajp_header.c?rev=307196&r1=234103&r2=307196
(In reply to comment #8) > Hi, > > I must dissagree with you. > The bug has nothing to do with Tomcat. > Tomcat works pretty well with mod_jk w or w/o SSL. > > The error is obviously in mod_proxy_ajp. Agreed, but I am not sure if the AJP connector on Tomcat side should set isSSL to true once it finds some of the SSL variables in the AJP message. From my point of view it should also ignore all SSL variables in the message if isSSL is set to false in the message.