It's quite probable that ctxhttp is racy in Go 1.4. There isn't a way to do it in a non-racy way for Go 1.4, though (that's why the net/http API changed in Go 1.5).

@dsymonds this method that I linked to above is racy?

@pwaller would that approach work if there was no request body?

The 1.4 support is racy, yes. I'm not too inclined to invest in fixing it though since a correct solution is going to increase complexity dramatically for little benefit.

@okdave, I understand that it works if there is no request body, yes. The body is written as part of Request.Write(conn), which reads the body, if it is present (which it is, in the reverseproxy example). So it is certain to be read from if it's not nil, even if there are zero bytes to read.

I'd like to see this fixed this because it means leaking connections and goroutines to docker in go-dockerclient, which a long lived process of mine uses. I want to implement cancellation in go-dockerclient in terms of ctxhttp but don't feel comfortable doing so while I know there is some chance that connections are leaked if someone is unlucky enough to build with go 1.4. The presence of this leak makes it harder to identify and diagnose other leaks.

The failure I'm concerned about is particularly pathological because the other side (docker) of the connection will hold the connection open indefinitely in some cases, so it could quickly run out of file descriptors and leak an unreasonable number of goroutines.

By avoiding the complexity in the library, that is pushing it onto the users! :)

By the way, I just ran the ctxhttp tests under go1.4 with this tweak:

func canceler(client *http.Client, req *http.Request) func() {
    rc, ok := client.Transport.(requestCanceler)
    if !ok {
        return func() {
            log.Printf("Not a canceler: %T", client.Transport)
        }
    }
    return func() {
        log.Printf("Using 1.4 canceler")
        rc.CancelRequest(req)
    }
}

The output is this:

=== RUN TestCancel
2015/11/18 08:57:32 Not a canceler: <nil>

This would appear to indicate that the tests aren't exercising the canceller on go1.4, and possibly the canceller is having no effect anyway?

(Also I hit this already fixed race in case anyone happens on it during investigation)

Interesting. ctxhttp.Do was not really designed with cancelling after it returned in mind. @broady, @bradfitz what are your thoughts on that?

I have opened #13325 for the above question of @okdave to avoid confusing this issue, which is about the go1.4 code being racy before the request is in flight.

(Aside: So now we have a problem where the request can't be cancelled before, and it can't be cancelled after, which means there is only a very "narrow" window — during the exchange of headers — where cancellation does anything. If that's ctxhttp working as intended, the documentation needs to be improved.)

Note: I ended up not using this for my original use case, so I'm unlikely to follow this up. I don't suppose anyone else is either, since 1.4 is soon to be two major versions behind and few people are likely to hit this. I would be OK with closing this issue.

We may as well leave this open to actually drop the Go 1.4 support soon.

It's been removed.