httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <ruediger.pl...@vodafone.com>
Subject Re: ping for http in mod_proxy
Date Thu, 14 Feb 2008 11:44:16 GMT
 

> -----Ursprüngliche Nachricht-----
> Von: Akins, Brian [mailto:Brian.Akins@turner.com] 
> 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" <jim@jaguNET.com> 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
  

Mime
View raw message