On Thu, Oct 08, 2015 at 12:27:07AM -0700, Joseph Lynch wrote: > Hi Shawn, > > I am pretty sure that HAProxy cannot retry requests themselves because > it does not know what side effects the request had. It can retry > connections but once the session is assigned it returns results or > fails. > > See Willy's response for some more detail: > http://marc.info/?l=haproxy&m=141225667313851&w=2 (you can also search > the mailing list archives and this has come up a lot).
Yep though the one you quoted above was a bit extreme :-) In Shawn's case, the problem basically remains the same issue with non-idempotent HTTP requests that *must not* be replayed without the user's consent (hence why only the browser can do that), and the fact that once the request leaves haproxy, it's not there anymore so there is no way to replay something we don't have. What I'm wondering is if it would be possible to return a redirect to the browser so that it posts it again in this case (eg, rediret to '#'). But anyway one of the difficulties is to identify that the response will fail, because if I understand the issue, the headers are there but not the body, and we're taking the decision on the headers. Is the response closed when this happens (eg: server crash) ? If so, we could add some sample fetches to detect that the request or response channels are closed in case that could help. This is trivial to do, but it will only be reliable if the close is immediately encountered, so it still depends on the timing. Regards, Willy
