Closed
Description
by eyakubovich:
What does 'go version' print? go version devel +5c372df9654a Wed Oct 15 13:33:00 2014 -0400 linux/amd64 What steps reproduce the problem? If possible, include a link to a program on play.golang.org. 1. Run the http server: http://play.golang.org/p/J-DOxv7l8P The server accepts connections and abruptly closes them via timeout. 2. Run the client program designed to illustrate the bug: http://play.golang.org/p/J-DOxv7l8P What happened? Here's an output of a sample run: [] resp err= Get http://localhost/foo: EOF [] resp err= Get http://localhost/foo: EOF [] resp err= Get http://localhost/foo: EOF [] resp err= Get http://localhost/foo: EOF [] resp err= Get http://localhost/foo: EOF [] resp err= Get http://localhost/foo: read tcp 127.0.0.1:80: connection reset by peer [] resp err= Get http://localhost/foo: http: can't write HTTP request on broken connection [] resp err= Get http://localhost/foo: EOF What should have happened instead? The client makes independent http requests in a loop and each line is the result of the request: either an error or body. All requests should produce the same behavior -- it can be an empty body or EOF error when performing ioutil.ReadAll(resp.Body). The request itself should not fail. Furthermore, at least some of the requests currently fail immediately as they are attempted to be made on already broken connections. Please provide any additional information below. I would like to emphasize that the problem is with the HTTP client, not the server. The demo server is there to exercise the client into handling broken connections. From doing preliminary investigation, it looks like the first time the http client properly returns empty body but the transport ends up returning the broken connection back to the pool. This results in the next request failing and transport "cleaning itself out", causing the pattern to repeat.