Re: option redispatch clarification
Hello, Thank you for taking the time to answer in detail. În ziua de vineri, 10 noiembrie 2017, la 18:24:09 EET, Willy Tarreau a scris: > On Fri, Nov 10, 2017 at 06:05:06PM +0200, Arthur Titeica wrote: > > If this doesn't work is there some other mechanism to achieve something > > like this? > > Aside the fact that you MUST never ever do this on non-idempotent requests, > I don't see an easy way to do it as it would require to keep a complete copy > of the request and to try to send it again. We've already thought about > ugly solutions like rebuilding a new request upon certain responses, but > for now there's nothing satisfying. I understand that this is a complicated issue. I'm glad though that I got it out of the system as I always had the impression that it will work like that. Regards Arthur
Re: option redispatch clarification
Hello Arthur, On Fri, Nov 10, 2017 at 06:05:06PM +0200, Arthur Titeica wrote: > Hello, > > I'm trying to understand if the redispatch option may be used to retry a HTTP > connection in the following scenario: > > Suppose there are multiple backend web servers and the first one that gets > chosen has a problem and replies with a 4xx or 5xx http status code. > > Will the connection be retried to the next backend webserver in the hope that > everything will work OK and we get a http 200 reply? No if any single byte was sent to the server (hence lost). Yes if the error happened before the request was sent (eg: connection refused, timeout). > If this doesn't work is there some other mechanism to achieve something like > this? Aside the fact that you MUST never ever do this on non-idempotent requests, I don't see an easy way to do it as it would require to keep a complete copy of the request and to try to send it again. We've already thought about ugly solutions like rebuilding a new request upon certain responses, but for now there's nothing satisfying. Regards, Willy
