1. Create a simple web app and serve it with ajp 2. In the web app, create a normal page (with .js, .css, and images), then craft a slow page that only returns a response after 1 second 3. Setup a reversed proxy to the web app with mod_proxy_ajp (a plain ProxyPass line) 4. Enable mod_deflate for the usual content types 5. Open Firefox, go to about:config, and set network.http.accept-encoding from "gzip, deflate" to an empty string 6. Restart Firefox, clear cache 7. With Firefox, access the normal page and let it load to completion, then access the slow page and press "Ctrl-W" to close the tab before the response is returned 8. Open Chrome, clear cache 9. With Chrome, access the normal page and see things go haywire, e.g. a request for a .js file will receive a response of image/png The symptom of mixed up response is similar to bug 40310 and bug 47714. In production system, other than broken functionality caused by .js file returned as image, our users were able to see responses intended for others. Once things go haywire, a graceful reload of Apache will get things to work again (leaving browser and proxy caching aside), until the next non-gzip client abandons a page load.
Actually, step 4 and 5 are just red herring. I can reproduce the bug without enabling mod_deflate and with a normal Firefox.
(In reply to comment #1) > Actually, step 4 and 5 are just red herring. I can reproduce the bug without > enabling mod_deflate and with a normal Firefox. Which version of Tomcat did you use? Any changes to the default configuration of the Tomcat AJP connector or (apart from the mentioned one ProxyPass line) to mod_proxy configuration? Could you please provide your Tomcat server.xml? Can you reproduce with the Tomcat standard ROOT context plus a slow.jsp with the following contents? <%Thread.sleep(4000);%> Done. Regards, Rainer
This was assigned CVE-2012-3507. It has been fixed in r1373955 for trunk and r1374297 for 2.4.x and was released today with version 2.4.3. Not 2.2 version is affected.
Oups, I meant CVE-2012-3502.