Arthur Țițeică
option redispatch clarification
November 10, 2017 05:10PM
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?

If this doesn't work is there some other mechanism to achieve something like
this?

Thanks
Arthur
Willy Tarreau
Re: option redispatch clarification
November 10, 2017 05:30PM
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
Arthur Țițeică
Re: option redispatch clarification
November 13, 2017 12:20PM
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
Sorry, only registered users may post in this forum.

Click here to login