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 <[EMAIL PROTECTED]> 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
>
>
