[Bug 54526] New: mod_proxy_http ignores request abortion

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54526

            Bug ID: 54526
           Summary: mod_proxy_http ignores request abortion
           Product: Apache httpd-2
           Version: 2.4.3
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_proxy_http
          Assignee: bugs@httpd.apache.org
          Reporter: pavel@netsafe.cz
    Classification: Unclassified

Hi,
our application is affected by "Double Execution of onload and
onreadystatechange Events for Script Elements" bug in IE9. See
http://msdn.microsoft.com/en-us/library/ie/hh180173(v=vs.85).aspx

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:
123.123.123.123 - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200 -
123.123.123.123 - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200
9376

Log from application:
123.123.123.123 - - [01/Feb/2013:14:01:15 +0000] "GET /main.css HTTP/1.1" 200
9376 300100937
123.123.123.123 - - [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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 54526] mod_proxy_http ignores request abortion

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54526

--- Comment #2 from Pavel Mateja <pa...@netsafe.cz> ---
Hi.
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 54526] mod_proxy_http ignores request abortion

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54526

--- Comment #1 from Yann Ylavic <yl...@gmail.com> ---
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...

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org