Hi, Willy Tarreau wrote: > As explained above, it's because a keep-alive enabled client must implement > the ability to replay requests for which it didn't get a response because > the connection died. In fact we're forwarding to the client what we saw on > the server side so that the client can take the correct decision. If your > client was directly connected to the server, it would have seen the exact > same behaviour.
One of the problems we saw when trying to reproduce this issue was that some clients I tried (i.e. curl 7.45.0 and ruby's httpclient gem) silently replayed any requests for which they didn't receive an answer. This can result duplicated POSTs on the backend servers. Often, servers continue to handle the first POST, even after HAProxy closed the backend connection because its server timeout stroke. Now, the client just replays the POST again resulting in potentially fatal behavior. If I understand the HTTP specs correctly, this replay is correct from the clients perspective as they can't know if they are speaking to a loadbalancer or an origin server directly. As a loadbalancer however, HAProxy should always return a proper HTTP error if the request was even partially forwarded to the server. It's probably fine to just close the connection if the connect timeout stroke and the request was never actually handled anywhere but it should definitely return a real HTTP error if its the sever timeout and a backend server started doing anything with a request. You could probably argue to differentiate between safe and unsafe methods and to also just close for safe ones but is probably even more confusing and has the potential for subtle bugs. Best, Holger
