Hi Elias, On Fri, Oct 15, 2021 at 11:45:30AM +0200, Elias Abacioglu wrote: > Hi > > I have backends with `default-server tfo`. > I also have `retry-on conn-failure` on every backend except one where I > have `retry-on all-retryable-errors`. > > I still get this warning for every backend. > > [WARNING] (9572) : parsing [/etc/haproxy/haproxy.cfg:332] : backend > 'cookie_backend': server 'dogfight03' has tfo activated, the backend should > be configured with at least 'conn-failure', 'empty-response' and > 'response-timeout' or we wouldn't be able to retry the connection on > failure. > > Is this a bug or do I need to have `retry-on conn-failure empty-response > response-timeout`? > Isn't it bad to have `retry-on response-timeout`?
In theory it could be bad, but with TFO you never know. The request gets sent with the SYN, so from haproxy's perspective, if the sendto() succeeds, it's gone. If the packet gets blocked, or if the data are ignored by the host, you end up with a connection that's waiting for its request while it was sent, effectively causing a response timeout. And it's not just a matter of supporting the feature or not. In my tests, TFO would randomly stop working and come back some time later, very likely as a protective measure under load. Maybe we could think about a "tfo" retry option, which would enable all those but only in case TFO was used. This would cover only the first idempotent requests of a connection that are sent using TFO without affecting other ones, and would also be easier to configure. I don't know how easy it is to implement since I don't know if we keep the info somewhere that TFO was used, but overall it should not be too complicated. Are you interested in having a look at this and trying to write a patch for this ? I can provide you some guidance if needed. Willy
