net/http: with Transfer-Encoding: chunked, Transport doesn't reuse the tcp connection

[jerome-laforge]

1. With both below versions:

   • go version go1.6.2 linux/amd64
   • tip devel +b66b97e Mon May 16 15:05:04 2016 +0000,

2. On Arch Linux, go env:

   GOARCH="amd64"
   GOBIN=""
   GOEXE=""
   GOHOSTARCH="amd64"
   GOHOSTOS="linux"
   GOOS="linux"
   GOPATH="/home/jerome/go"
   GORACE=""
   GOROOT="/usr/lib/go"
   GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
   GO15VENDOREXPERIMENT="1"
   CC="gcc"
   GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
   CXX="g++"
   

3. With this program https://play.golang.org/p/HHqlKiVR4o

4. I expect that http client reuses the tcp connection for first and second http request.
   The problem is describe more deeply here:
   go-kit/kit#249

5. Sometime, the http client doesn't reuse the tcp connection between first and second http request (I check it with Wireshark filter on port given into the log e.g. tcp.port == 35068).

   When the tcp connection is not reused, delve shows me that (https://github.com/golang/go/blob/master/src/net/http/internal/chunked.go#L61) cr.r.Buffered() return 0, and EOF isn't read (https://github.com/golang/go/blob/master/src/net/http/internal/chunked.go#L56), as the last 0 that indicates the end of chunked response isn't read.
   So http client send a tcp reset to http server and open a new tcp connection.

   If I drain the response.Body (with io.Copy(ioutil.Discard, resp.Body)), the tcp connection is always reused by the http client (even is cr.r.Buffered() returns 0)

[bradfitz]

More interesting is that removing the redundant "Connection: keep-alive" header (which is implicit with HTTP/1.1) seems to matter. It usually (also odd) works when you don't set that header.

Related previous stuff: rev 18072ad and #14867 and google/go-github#317

[bradfitz]

Actually, I had misread your repro code the first time. This is working as intended.

The lack of connection of reuse (that I see 40-60% of the time with your repo) isn't due to chunked encoding, but because the handler hasn't yet finished when you call resp.Body.Close().

If you put a time.Sleep(10 * time.Millisecond) or even shorter after your flush and before the handler, you can see that it it doesn't reuse the connection 100% of the time.

And if you move the rw.(http.Flusher).Flush() call to before the JSON write (so you're still sending chunked encoding), then you see it reuses the connection 100% of the time.

The race you're seeing is because depending on goroutine scheduling.

You have two goroutines, S(erver) and C(lient):

• S: write, flush, send EOF (at handler func return)
• C: decode, close

You're seeing them sometimes scheduled like this:

• S: write
• C: decode
• C: close (at it hasn't seen EOF yet, so it's right to close the connection and not reuse it)
• S: flush / send EOF (neither of which matter, since the client has hung up on us anyway)

That is a valid result.

I recommend you remove the flush.

I've added a new test in https://golang.org/cl/23200 to guarantee the existing behavior when the flush is in the right spot.

Please let me know if I misunderstand something.

[gopherbot]

CL https://golang.org/cl/23200 mentions this issue.