the one that initiates the HTTP connections. Make sure that the keep-alive connection timeout is lower on the client end i.e. The same thing is being reported by the error message in our Golang program: our “browser” or, in other words, a client using http.Transport did not send any request so that was sent to a background goroutine that kept track of the keep-alive connection, and because no actual request had been sent, it was marked as an error and that was printed to the console to inform the user what had happened. Of course, it is not a real time system so a margin of error of a few milliseconds is OK.

As you can see, the actual duration of the connection is very close to the actual timeout value – 10 seconds. Obviously, this had happened because the keep-alive connection reached the timeout value and then it was closed automatically. The capital C letter means that the connection was closed from the haproxy side. Let’s also analyze the haproxy log messages which are being printed whenever this happens.

Thus, to fix it, you need to have identical IdleConnTimeout on both ends. The error message mentioned in the first paragraph comes up when that certain HTTP probe is being sent but the server (in our case, haproxy) and at the same time, while the packets are on the wire, the connection has been already closed on the other end since it had timed out. On the haproxy end, it is controlled by timeout http-keep-alive in the configuration file. On the client side, this is controlled by IdleConnTimeout which is specified in http.Transport. However, it could happen that our client which uses http.Transport still expects the HTTP probe to work if there is a mismatch in the keep-alive timeouts on both sides. Those probes are periodical sends of bytes on HTTP sockets to see if the other end is “still alive”. To actually keep the HTTP connections alive, a certain liveness check is needed. So by disabling it, harmless messages about all locked goroutines are avoided when the main goroutine is blocked as well due to performing some other actions. Otherwise, that tracking would have to “bubble up” back to the caller. If you might not have known, once you start using the net/http package, it disables the embedded albeit rudimentary Go’s dead-lock checker if keep-alive connections are used because it internally spawns new goroutines to keep track of them. This blog post goes through the reasons why that happens, if it is harmful, and how you can avert these kinds of things. It is very useful – usually other libraries want variables of types which implement that interface – however, you might have noticed that using it in combination with haproxy and HTTP keep-alive connections sometimes make these kinds of messages appear in your program: 1 11:22:33 Unsolicited response received on idle HTTP channel starting with 'HTTP/1.0 408 Request Time-out Cache-Control: no-cache Connection: close Content-Type: text/html 408 Request Time-out Your browser didn't send a complete request in time. ' err=Īnd in your haproxy logs: Aug 21 11:22:33 myhost: 1.2.3.4:44444 http~ http/ -1/-1/-1/-1/10050 408 212 - cR- 0/0/0/0/0 0/0 '' Golang’s standard library’s http package provides a type http.Transport which implements some low-level methods for transporting HTTP requests hence the name.

Golang http client timeout