httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Woodworth" <>
Subject Re: mod_proxy race condition bug #37770
Date Mon, 19 May 2008 19:36:40 GMT
So let's consider the case of a web browser that uses keepalives.  If
the web browser has a keepalive connection, and the connection closes
behind it's back so that the next time the browser tries to use the
connection it fails (like this problem we're having with mod_proxy),
what should the web browser do?

I bring this up because while I certainly never see Firefox regularly
fail to load pages, I'm seeing mod_proxy fail with some regularity,
perhaps only a fraction of a percent, but still...  And you would
think you'd see the same problem with any sort of browser/proxy.

Has anyone seen the socket code for Firefox to see if they're doing
something more clever to prevent dead connections from being used?

On Mon, May 19, 2008 at 3:18 PM, Ruediger Pluem <> wrote:
> On 05/19/2008 06:09 PM, Adam Woodworth wrote:
>>> Index: modules/proxy/proxy_util.c
>>> +    /* Close a possible existing socket if we are told to do so */
>>> +    if (conn->close) {
>>> +        socket_cleanup(conn);
>>> +        conn->close = 0;
>>> +    }
>> Does this mean that sockets that should have been closed (via the
>> close flag) weren't getting closed correctly before?  I.e. sockets in
>> the pool were still "open" as far as mod_proxy was concerned even
>> though we set the close flag?
> No, it does not mean this. This patch is needed to correctly act, when the
> patch
> below kicks in. So far conn->close was *always* 0 at this point of code, but
> with the patch below it might not, as we might decide *before* reusing a
> connection
> that we better should not.
>> Why is the patch below necessary?  The comments indicate that if we
>> were to us an existing keepalive connection to the backend server, but
>> it failed, then if the client was NOT keepalive then we couldn't send
>> the failure to the client...but why?  If we fail to connect to the
> This is because the client does not expect this kind of failure in this
> situation and
> acts wrong. If it is the initial connection e.g. of a seamonkey browser it
> does not
> try to resent the request but simply displays an blank page which is bad for
> the user.,
>> backend, whether on a keepalive or non-keepalive connection, why does
>> it matter if the client is keepalive or not in order to send an error?
> We do not send an error, but we are closing the connection an expect to the
> client to handle
> this correctly which it does only if it used a kept alive connection.
> Regards
> RĂ¼diger

View raw message