Bug 41610

Summary:	mod_jk incorrectly creates duplicate content-length:0 header
Product:	Tomcat Connectors	Reporter:	Boris Maras <bmaras>
Component:	Common	Assignee:	Tomcat Developers Mailing List <dev>
Status:	CLOSED FIXED
Severity:	normal	CC:	step.pubinfo
Priority:	P2	Keywords:	RFC
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Attachments:	Packet captures of the duplicate content-length:0 Proposed patch in mod_jk.c

Description Boris Maras 2007-02-14 05:48:20 UTC

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.

Comment 1 Boris Maras 2007-02-14 05:56:14 UTC

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.

Comment 2 Boris Maras 2007-02-14 06:14:05 UTC

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

Comment 3 Boris Maras 2007-02-14 06:23:33 UTC

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.

Comment 4 Rainer Jung 2007-02-15 05:16:37 UTC

Thanks for the analysis. I committed you patch. It will be part of 1.2.21.

Comment 5 step_fr 2007-02-15 07:31:11 UTC

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

Comment 6 Rainer Jung 2007-02-15 11:06:18 UTC

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.

Comment 7 Rainer Jung 2008-01-01 16:32:31 UTC

Move a couple of fixed JK issues from resolved to closed.