Under specific circumstances, the mod_jk adds a content-length:0 header, even if there was already another content-length:0 header. Tomcat seems to handle it without problem. But if tomcat forwards the packet to another Apache, this second Apache sends an http 400 error (incorrect request), due to this duplicate header. We have this behavior when an empty (i.e. without any body) POST request is sent by Internet Explorer. This happens when IE tries to authenticate through NTLM with a POST request. We have the following architecture : Server 1 : - A: a web application (Jahia 5.0.1_02) running under tomcat 5.5.17 - B: an apache 2.0.40 running on the same server, with mod_jk 1.2.20 Server 2 : - C: a web application (Jahia cache server r370) running under tomcat 5.5.16 - D: an apache 2.0.40 running on the same server, with mod_jk 1.2.20 Both servers run with Linux Redhat. Tomcat A is configured to authenticate users through NTLM, with the java library jcifs 1.2.11 Tomcat C behaves (roughly) as a reverse-proxy : it sends the packets to Apache B. Apache B and D have been set up to implement optional SSL encryption. NTLM authentication is made with Active Directory 2003. If I send my requests to Apache D, I have the http 400 error with every POST request. By sniffing the packets, I discovered that this http error was sent by Apache B, and not D. If I send my requests to Tomcat C, I don't have any http 400 errors. The duplicate content-length:0 is created by Apache D, accepted by Tomcat C, but refused by Apache B. These http errors happen with or without SSL encryption. They do not happen if I disable NTLM authentication on Tomcat A, probably because no empty POST requests are sent.
We tried an upgrade to Apache 2.0.59 (with mod_jk-apache-2.0.58.so) and Apache 2.2.4 (with mod_jk-apache-2.2.3.so) : not better.
Created attachment 19590 [details] Packet captures of the duplicate content-length:0 These are 4 packet captures that follow a single packet through the servers : client -> Apache D -> Tomcat C -> Apache B -> Tomcat A We can see in these captures that : - the client sends only one content-lenth:0 header - Apache D sends duplicate headers - Tomcat C re-sends the same duplicate headers - Apache B rejects the request and does not send anything to Tomcat A
Created attachment 19591 [details] Proposed patch in mod_jk.c Our problem has been solved with the following patch in mod_jk.c The code seems to look for an existing content-length header before adding the content-length:0 header. So it loops through the headers and compares them to the string "content-length". But the comparison was made on the header values. We changed it to make the comparison on the header names.
Thanks for the analysis. I committed you patch. It will be part of 1.2.21.
YEPLA! Our first committed bugfix in such a great project ! Thanks Rainer for such a quick answer and thanks for all the work done by the apache team. The patch has been backported for our use in version 1.2.19 and also works without any problem. We didn't study porting this patch to 2.2.x version but it seems to have a similar behaviour. PS for boris :D APERO !!
I applied the fix to the Apache 1.3 and 2 code lines of mod_jk. The Apache 2 code line fixes it for 2.0 and 2.2.
Move a couple of fixed JK issues from resolved to closed.