On Tue, Aug 28, 2018 at 11:11:52AM +0000, Edward Hibbert wrote: > This is partly a FAQ, but hopefully it goes beyond that...into a more subtle > FAQ, perhaps. > > I understand that in general it is dangerous for haproxy to retry a request > once it has been sent to a server, for example after a timeout or error, > because the server may not be idempotent. I get this objection. > > However there are some backends that are designed to be idempotent, or where > the consequences of retrying an operation are less bad than the consequences > of clients timing out. I have servers supporting an AJAX API over HTTP which > are designed in this way, partly because HTTP client retries can result in > duplicate POST requests anyway. > > It would be lovely if there was an option to retry in such situations, with > suitable caveats.
We're already aware of this. It's not only a matter of option but a matter of important infrastructure changes. It's one of the long-term goals of the current redesign of the HTTP layer. If haproxy is efficient it's because it ensures it passes data from one end to another as fast as possible, and by doing so it never keeps a track of an already forwarded request. See it as a router. You wouldn't expect your router to retransmit the packets that have been lost. Here it's the same. So L7 retries will require to keep a copy of the request that is being forwarded, in hope to be able to retry it. It will obviously be limited to short requests which entirely fit into a buffer (thus not large POSTs). And it will also significantly increase memory usage since the copy of the request will have to be kept for the time it takes to the server to respond. So basically instead of keeping it for one microsecond it will keep it for a few hundreds of milliseconds to a few seconds. This is why this will definitely not be enabled by default! Regards, Willy
