Re: option redispatch clarification

2017-11-13 Thread Arthur Țițeică
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

2017-11-10 Thread Willy Tarreau
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



option redispatch clarification

2017-11-10 Thread Arthur Țițeică
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