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: [email protected]
Reporter: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
