You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2015/08/24 17:53:47 UTC

[Bug 58280] New: Backend connection not closed until timeout if client prematurely closes connection

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: bugs@httpd.apache.org
          Reporter: s9flschr@stud.uni-saarland.de

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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 58280] Backend connection not closed until timeout if client prematurely closes connection

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58280

--- Comment #1 from Christophe JAILLET <ch...@wanadoo.fr> ---
This looks like a duplicate of bug 54526

-- 
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