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