Thanks for all the input guys. Sounds like haproxy is the wrong place to solve the problem, so we've instead decided to remove nginx from the equation (which was only providing gzip capabilities that we can implement directly in our webserver). Thus, requests failing on the webserver will actually result in disconnects, which will allow haproxy to redispatch the request to a new server.
On Tue, Aug 24, 2010 at 2:53 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Tue, Aug 24, 2010 at 12:52:20AM -0600, Jerry Champlin wrote: > > In that case I'm not sure how to make it work. Seems like you will need > to > > modify http_proto.c to cause the request to attempt to be redispatched > when > > haproxy receives a valid 502 http response from the server. I doubt that > > this is the only thing to change, but it probably involves changing this > > section of code and others: > > it won't work. > > Haproxy tries to redispatch as far as it can. If you see a 502, that > means that the request was *really* forwarded and that it does not have > it anymore. So it won't be able to redispatch it to anyone else. > > That's one reason some people like to put caches such as nginx or > varnish before or after haproxy. Caches by their nature are able to > replay a request if they consider it is not risky, because they keep > a copy of it. > > Regards, > Willy > >
