This is an unfortunate part of the http/1 spec (http/2 makes this much better with the goaway messages so the client knows for sure if the server processed the request)
Including the time out in the header is nice, although I'm not sure how many clients/client libraries will pick up on that. I've added it in other work with pretty good results; especially if you advertise one second less than you'll actually wait, that would eliminate the request and close crossing in transit except in case of missed packets and retransmits. -- Richard Russo to...@enslaves.us On Thu, Mar 21, 2019, at 10:37 AM, Robert Higgins wrote: > Hi, > > I am encountering a problem with http 1.1 clients that reuse their > connection just at the same moment that HAProxy is closing it, > resulting in socket hangup ECONNRESET style errors. Version is 1.9.4. > > In our haproxy config we have something like : > > timeout http-keep-alive 5s > > A client who: opens a connection, does a number of requests, then idles > for 5 seconds before firing off another requests will sometimes > encounter an error. The server is close the socket while the client is > sending the last request. The client must retry/handle the error > gracefully. > > We can avoid the problem by setting a similar timeout client side so > that they do not try to reuse a connection that has been idle for say, > 4 seconds, but this is difficult to manage when we cannot control all > the clients. > > The timeout parameter of the Keep-Alive header seems like it could help > : > https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#p-timeout > > I'd almost expect HAProxy to add the Keep-Alive header when it sees > Connection: Keep-Alive in the request, but maybe that's going too far. > > Is it a good practice to do some header manipulation to communicate > this timeout from HAProxy to the client ? I.e. : > > timeout http-keep-alive 5s > http-response set-header Connection Keep-Alive > http-response set-header Keep-Alive timeout=4 > > Having HAProxy indicate the correct timeout value would be more > manageable that implementing it in each of our clients ... > > Regards, > > Robert Higgins > >
