Bug 40310 - Ajp Connection handling causes unexpected results.
Summary: Ajp Connection handling causes unexpected results.
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.2-HEAD
Hardware: Other All
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
Depends on:
Reported: 2006-08-24 16:15 UTC by Ian Abel
Modified: 2012-08-16 06:02 UTC (History)
1 user (show)

Patch that attempts to fix the bug (525 bytes, patch)
2006-08-24 16:17 UTC, Ian Abel
Details | Diff
patch for 2.2.x (2.20 KB, patch)
2007-03-22 09:41 UTC, jfclere
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Abel 2006-08-24 16:15:58 UTC
With an apahce proxying requests over ajp to a backend tomcat, the following 
sequence of events is possible:

User1 requests /badger, and sends headers.
Request hits apache, filters into ap_proxy_ajp_request in mod_proxy_ajp.c
User1 terminates connection with extreme prejudice.
Apache sends headers to tomcat.
Tomcat takes it's time.
Apache tries to read the rest of the request body with ap_get_brigade, 
mod_proxy_ajp.c:174. This fails as the underlying socket cannot recv any more.
So ap_proxy_ajp_request returns 500 immediatly. conn->close++ is not called so 
the connection is not touched, merely put back in the available connections.
Apache now fails int he output filters trying to send the status 500 error 

Now user2 connects, requests /moose, apache takes the above connection from the 
pool and sends the headers down the pipe to the tomcat.
The tomcat now returns /badger, as that's finally finished processing. 
Apache in ajp_read_header reads the SEND_BODY_CHUNK message, and processes it. 
Then repeats reading messages until the END_RESPONSE message.

Whereupon apache has successfully served /badger to someone who requested /

Needless to say this is a critical flaw with the ajp connection handling.
Comment 1 Ian Abel 2006-08-24 16:17:49 UTC
Created attachment 18750 [details]
Patch that attempts to fix the bug

This patch _should_, if my understanding of the bug is correct , fix it.
Comment 2 Ruediger Pluem 2006-08-24 19:52:49 UTC
Well spotted! Committed to trunk as r434483
(http://svn.apache.org/viewvc?view=rev&revision=434483). Thanks for the patch.
Comment 3 Ruediger Pluem 2006-08-24 19:58:31 UTC
Proposed for backport to 2.2.x as r434488
Comment 4 Russell Hatfield 2007-01-04 10:52:34 UTC
I'd like to add that in our shop we witnessed this exact same problem with
Apache 2.2.3 and mod_jk 1.2.19, not mod_proxy_ajp.  Will the fix being applied
cure this problem when using mod_jk or is a seperate patch going to be applied
to that module as well?

Comment 5 Ruediger Pluem 2007-01-04 11:40:34 UTC
No this will not cure mod_jk. Bugs for mod_jk should not be further handled in
this report. Please open a new report with Product: Tomcat 5 and Component:
BTW: The fix for the original bug will be part of 2.2.4 as it has been backported.
Comment 6 jfclere 2007-03-17 11:44:58 UTC
The problem is still not fixed correctly in 2.2.4 (the worker is marked errored
and connection retried but that is wrong):
Fri Mar 16 08:27:06 2007] [error] [client] proxy: error processing
body, referer: https://xxx.yyy.zzz/site/checkout/ship_method.html
[Fri Mar 16 08:27:06 2007] [error] proxy: got bad response (5) from (app4)
[Fri Mar 16 08:27:06 2007] [error] proxy: BALANCER: (balancer://appservers). All
workers are in error state for route (app4-engine1)
I have fixed it in trunk.
Comment 7 jfclere 2007-03-22 09:41:29 UTC
Created attachment 19772 [details]
patch for 2.2.x

I will commit it in the 2.2.x branch if noone complains.
Comment 8 Ruediger Pluem 2007-08-17 13:07:58 UTC
Fix backported to 2.2.x as r553593
Comment 9 Yap Sok Ann 2012-08-16 01:41:31 UTC
Here's a report for the same symptom with httpd-2.2.11:


Meanwhile, I just experienced the same with httpd-2.4.2

I can't rule out the possibility of bug in my application code, misbehaving proxy server, etc. However, the mixed up response only happens with mod_proxy_ajp, not mod_proxy_http.
Comment 10 Yap Sok Ann 2012-08-16 06:02:04 UTC
I have logged a separate issue: bug 53727