https://bz.apache.org/bugzilla/show_bug.cgi?id=58280
Bug ID: 58280
Summary: Backend connection not closed until timeout if client
prematurely closes connection
Product: Apache httpd-2
Version: 2.4.16
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_http
Assignee: [email protected]
Reporter: [email protected]
In a reverse proxy scenario, if the client closes the connection after sending
the request headers, the backend might still run into a timeout, although its
connection could be closed immediately.
Actual scenario/how to reproduce:
* Using a simple netcat reverse proxy backend (balancer)
* Setting Timeout/ProxyTimeout to X
* Client sends some arbitrary GET request and closes the connection
* Backend either:
* does nothing, resulting after X seconds in: (70007)The timeout specified
has expired: [client 192.168.150.2:48056] AH01102: error reading status line
from remote server
* sends "200 OK" with some Content-Length (without or with less body),
resulting after X seconds in: (70007)The timeout specified has expired: [client
192.168.150.2:48094] AH01110: error reading response
Why this might be bad in my scenario:
For some backends (such as in my case Microsoft-Server-ActiveSync), a high
timeout might be desirable/required. For me, these are some kind of
long-polling requests with the response having a huge Content-Length (that
won't be reached), just in case some data has to be "pushed". Now, as described
above, for each client connection that gets closed, a backend-connection might
be idling until its (huge) timeout gets reached. Imho these connections should
be closed (as it is pointless to read) and impose a kind of DoS risk.
I would expect to "propagate" the hard connection-close after seeing a close
event from the client connection.
Or am I mistaken and this is a desired behaviour (maybe for connection pooling
purposes)? If so, could it be overridden by means of configuration/patch?
--
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]
