> -----Ursprüngliche Nachricht----- > Von: Akins, Brian [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 14. Februar 2008 12:37 > An: dev@httpd.apache.org > Betreff: Re: ping for http in mod_proxy > > On 2/13/08 1:09 PM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote: > > > And again, we're basically doubling traffic and adding > > overheard (more overhead than AJP's cping/cpong) at which > > point I go back into wondering whether this sort of > > implementation makes sense at all... > > > So is the main issue we are trying to solve is that we have a > keepalive > connection to an origin but it does away (closes) before we > make or next > request and this causes an "error." (Sorry if I'm behind on > the thread.)
Basicly yes. > Shouldn't the HTTP client handle all of this? I know that > libcurl handles > this situations very well - it just tries to reconnect. How does serf > handle it? There are two problems here: 1. We currently have no mechanism in place that "simulates" these kind of failures we experience ourselves with the backend for the client. Returning a 500 or 503 does not cause the client to repeat the request. IMHO we would need to cut off the network connection without sending anything to trigger this behaviour in a well designed client. 2. Clients are only allowed to resend the request automatically, if the request was idempotent. Clients are not allowed to do so with non-idempotent requests like POST's without user intervention. So by probing the keepalive connection before sending the request we want to reduce these cases. Regards Rüdiger
