net/http: empty responses with chunked transfer-encoding cause future requests to fail

[gopherbot]

by eyakubovich:

What does 'go version' print?

go version go1.3.1 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Run a server that closes a connection by timeout: http://play.golang.org/p/qfkdd6hDat
2. Run the client: http://play.golang.org/p/hxTAdcdrOY

What happened?

The first request succeeds (get empty body) but subsequent requests intermittently fail.
Client output:

2014/09/03 17:53:56 []
2014/09/03 17:53:56 resp err= Get http://localhost/foo: EOF
2014/09/03 17:53:57 []
2014/09/03 17:53:57 resp err= Get http://localhost/foo: EOF
2014/09/03 17:53:58 []
2014/09/03 17:53:58 resp err= Get http://localhost/foo: EOF
2014/09/03 17:53:59 []
2014/09/03 17:53:59 resp err= Get http://localhost/foo: http: can't write HTTP request
on broken connection
2014/09/03 17:54:00 []
2014/09/03 17:54:00 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:01 []
2014/09/03 17:54:01 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:02 []
2014/09/03 17:54:02 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:03 []
2014/09/03 17:54:03 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:04 []
2014/09/03 17:54:04 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:05 body err= unexpected EOF
2014/09/03 17:54:06 []
2014/09/03 17:54:06 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:07 []
2014/09/03 17:54:07 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:08 []
2014/09/03 17:54:08 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:09 body err= unexpected EOF
2014/09/03 17:54:10 body err= unexpected EOF
2014/09/03 17:54:11 []
2014/09/03 17:54:11 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:12 body err= unexpected EOF
2014/09/03 17:54:13 []
2014/09/03 17:54:13 resp err= Get http://localhost/foo: EOF
2014/09/03 17:54:14 body err= unexpected EOF
2014/09/03 17:54:15 []


What should have happened instead?
- Subsequent requests should behave identically by returning empty body.
- Note that the server may have closed the connection abruptly. That can result in
resp.Body.Read() failing. However the Get() should not fail with EOF.


Please provide any additional information below.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.4.

[gopherbot]

Comment 2 by eugene.yakubovich@coreos.com:

Updated server to close response body explicitly: http://play.golang.org/p/qqPRYcCvze
Same problem persists.

[rsc]

Comment 3:

Status changed to Accepted.

[rsc]

Comment 4:

Brad, can you look at this? Please fix or postpone to 1.5.

[kelseyhightower]

Comment 5:

Brad, if this is relatively straight forward I'm happy to help on this one. Any hints on
where this should be fixed?

[bradfitz]

Comment 6:

Will do.
Kelsey, what I would do is write a test that reproduces it first (this would be useful
by itself), and then trace through the server "life of a write" (search for that
comment) path and see why it's happening. The fix is probably tiny but I won't know
until I know what's happening.

[bradfitz]

Comment 7:

As far I can tell, this is a dup of issue #8534. The issue here isn't about chunked
encoding or empty responses, but entirely about reuse of connections after a write error.
But even with the fix to issue #8534, the client/server test programs in this bug won't
do anything useful.
Let me know if I missed something.

Status changed to Duplicate.

Merged into issue #8534.

[gopherbot]

Comment 8 by eyakubovich:

Just tried again with the latest version that includes this change and the problem
persists. As I understand it, issue #8534 is about the server not handling write timeout
properly. This bug is about the client returning broken http connections back to its
pool without closing them.

[bradfitz]

Comment 9:

That was not clear at all from the initial subject and bug report.
Could you try again to summarize the problem and provide code which demonstrates the
problem?  The server code you provided here is not useful.  It's not clear what you're
trying to tickle and is poking at too many things.
I would file a new bug because this one is already too confused.

[gopherbot]

Comment 10 by eyakubovich:

Issue refiled as 8946.