Bug 54526

Summary: mod_proxy_http ignores request abortion
Product: Apache httpd-2 Reporter: Pavel Mateja <pavel>
Component: mod_proxy_httpAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: 2.4.3   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description Pavel Mateja 2013-02-05 14:37:31 UTC
our application is affected by "Double Execution of onload and onreadystatechange Events for Script Elements" bug in IE9. See

It means when IE9 loads one HTML page twice. First hit is aborted when the second occures.
There are CSS, JS and images on that page. Sometimes they started being served as part of first hit but the request is aborted almost immediatelly.

Our application is behind reverse proxy. All traffic is thru HTTPS.

The problem is that sometimes the reverse proxy keeps established connection to backend until the backend times out.

Log from reverse proxy: - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200 - - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200 9376

Log from application: - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200 9376 300100937 - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200 9376 12003
The last number is %D - The time taken to serve the request, in microseconds.

I was trying to reproduce this behavior but the time window to trigger the bug is too small.

We have enabled mod_deflate recently and the log has changed.
Now it reports it sent 26 bytes to client during such aborted request. The problem with established connection to backend persist.

I can see code in mod_proxy_http like:
if (ap_pass_brigade(r->output_filters, bb) || c->aborted)
but I'm not sure where in the code the "aborted" field is supposed to be set.

In similar code in mod_proxy_connect is the c->aborted check before ap_pass_brigade.
That would mean that right code is:
if (c->aborted || ap_pass_brigade(r->output_filters, bb))

My main concern is that somebody who knows exact timing to trigger the bug can DoS us.

Any hints?
Comment 1 Yann Ylavic 2014-01-13 15:02:28 UTC
mod_proxy won't check the client's connection while it is waiting for the backend's response, and in any case won't abort the latter based on the former being (half-)closed (the connection can't be read anymore, but still can be written to).

Why is the backend timeout-ing on the first request, it does not respond at all?
How does it know the client has aborted, based on a second request being received?

I don't see how mod_proxy could handle this, it is responsible for forwarding anything it gets in the configured time...
Comment 2 Pavel Mateja 2014-02-18 13:48:40 UTC
It's year back and we don't have such setup anymore.

But my impression was that things usually happened like:
client connects to reverse proxy, reverse proxy opens connection to backend, client sends request, proxy passes request to backend, backend responds, proxy passes response to client and client closes connection.

What sometimes happened was probably:
client connects to reverse proxy, reverse proxy opens connection to backend, client sends request and closes connection, proxy passes request to backend, backend starts to send response, proxy is trying to pass response to client's closed connection, backend closes connection to proxy due to timeout.

But I'm not sure. I saw such things in production logs only and I was unable to replicate them in test environment.