[go-nuts] On HTTP client request cancelation

Hi All,

Ref: [golang-dev] Possible race caused by http persistent connections
https://groups.google.com/d/topic/golang-dev/0Nl6k5Sj6UU/discussion

In the above discussion, I mentioned incidentally that using
http.*Transport.CancelRequest is tricky.

The background is that you can't call http.CancelRequest until you
know the request is in flight. So if you do something along the lines:

   req := &http.Request{...}
   go func() {
      <-requestShouldBeCancled
      transport.CancelRequest(req)
   }()

   client.Do(req)

Then this is racy. The problem is that with the current
implementation, CancelRequest() may have nothing to cancel if it beats
the Do(). To avoid the race you have to do something a bit contorted,
along the lines of what httputil.ReverseProxy does:

https://github.com/golang/go/blob/ab08f79af3d41e28bf2ccf2f8738024a1404aeac/src/net/http/httputil/reverseproxy.go#L130-L156

So, I was idly wondering: is there a good reason that the cancelation
state of a request lives on the transport, and not on the request?

If I were thinking about implementing this now, I would make Cancel a
method on the *Request, which would close a member variable of chan
struct{}.

Then clients could avoid worrying about a race, since the Do method's
internals would be able to check the req's cancel state when it comes
to starting the request.

Further idle thinking: can this transformation be done and
simultaneously maintain the API promise? I guess it seems doubtful,
since it would amount to a behaviour change of some sort. It would
make the API much less error prone if it were possible. I'm unable to
spend long enough thinking about this to rule out that it would break
existing legitimate code; hence this post.

The existing API could be kept, of course.
*Transport.CancelRequest(req) would just call the Cancel() method on
the `req`. There is a curious detail here that you could use
CancelRequest on a *Transport to cancel requests going over other
*Transports, but it's not obvious to me if/how this could be harmful.

Regards,

- Peter