CC @bradfitz

I can reproduce at least on Linux/amd64.

Notes:

• 0 to 3 in 2000 runs fails for me.
• creating a dedicated Transport just for this test (e.g. with newClientServerTest) doesn't fix it.
• disabling the CloseNotify calls doesn't fix it.
• closing Response.Bodies doesn't fix it.
• copying the bytes from Response.Body to ioutil.Discard (always zero, always nil io.Copy error) doesn't fix it.
• no races detected
• even a http.Handler of this single line still fails:

   w.Header().Set("X-Addr", r.RemoteAddr)

So this has nothing to do with either CloseNotifier, nor Hijack.

There are other tests which use this same pattern of doing two requests and verifying they report the same RemoteAddr as a proxy for determining whether the connection was re-used. One example is TestHandlerSetsBodyNil_h1 and _h2. It looks identical about I can't get it to flake.

I'm very confused.

Ah, the difference between TestHijackAfterCloseNotifier and TestHandlerSetsBodyNil_h1 is that the latter writes non-zero response bytes. And indeed, that seems to be the cause of the flakiness: if there are zero response bytes and a Content-Length of 0, the Transport sometimes creates a new connection rather than re-using the one it just replied with.

Sent https://go-review.googlesource.com/#/c/17890

Thanks for the quick fix :-)