Bug 54526 - mod_proxy_http ignores request abortion
Summary: mod_proxy_http ignores request abortion
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_http (show other bugs)
Version: 2.4.3
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-05 14:37 UTC by Pavel Mateja
Modified: 2014-02-18 13:48 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Mateja 2013-02-05 14:37:31 UTC
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?
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
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.