httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: mod_proxy race condition bug #37770
Date Mon, 19 May 2008 19:18:11 GMT

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.



View raw message