Sounds good, glad I was able to help. I'll keep an eye on this in a future httpd release.
On Sat, Sep 20, 2008 at 6:42 AM, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > > > On 09/20/2008 12:21 PM, Nick Kew wrote: >> >> On 19 Sep 2008, at 23:08, Ruediger Pluem wrote: >> >>> On 09/19/2008 11:24 PM, Adam Woodworth wrote: >>>> >>>> The problem with this is that it will also do this for connections to >>>> the backend that timed out. For our application, we want actual >>>> timeouts to be caught as normal and kicked back through to the client >>>> as a 50x error. >>> >>> Hm. Good point. I have to think about it, because a timeout error can >>> justify a repeated request (like when a firewall between frontend and >>> backend cut the connection and now the packets are simply dropped by >>> the firewall and a fresh one would fix this). >> >> I think Adam is right. The justification for the RFC-breaking connection >> drop is IIRC that it's merely propagating the same from the backend >> to the client. That doesn't apply in the case of a timeout. >> > > Yes, I came to the same conclusion in the meantime. The firewall drop can be > prevented by setting keepalive to on. Furthermore the typical keepalive > timeouts > for http connections are way below the typical firewall timeouts. So if we > get back APR_TIMEUP we can safely assume that the backend did not respond in > a timely manner. Looking at his patch I think it looks basically fine. > Hope to find some time for a closer look and a commit later on. > > Regards > > Rüdiger >
