Repository navigation
net/http: drop support for Transport.CancelRequest #79040
Description
The long-deprecated Transport.CancelRequest function cancels an in-flight HTTP request.
This function was deprecated in Go 1.6 (February 2016) in favor of Request.Cancel (added in Go 1.5).
In Go 1.13, Request.Cancel was superseded by NewRequestWithContext, which is now the only non-deprecated request cancellation mechanism.
The documentation for CancelRequest states:
CancelRequest cannot cancel HTTP/2 requests. This may become a no-op in a future release of Go.
Supporting CancelRequest for HTTP/1 requests is quite expensive, since it requires maintaining a map of currently in-flight requests against the possibility that the user might want to cancel one. It isn't feasible to maintain cancellation state on the *Request itself, since users can and do copy in-flight requests (*newReq := *req), which causes the race detector to complain if Transport.RoundTrip mutates the input request in any way.
CancelRequest has been deprecated for a decade, is now two cancellation mechanisms out-of-date, silently fails to work for HTTP/2 requests, imposes costs on code which doesn't use it, and is documented as something which may become a no-op.
I propose that we change Transport.CancelRequest to be a no-op and log a warning once on the first call:
package http
var cancelRequestOnce sync.Once
func (*Transport) CancelRequest(req *Request) {
cancelRequestOnce.Do(func() {
log.Println("Use of unsupported Transport.CancelRequest. Use NewRequestWithContext instead.")
})
}We will also add a GODEBUG to reenable support: GODEBUG=httptransportcancelrequest=1
The GODEBUG will persist for four release cycles (standard lifetime proposed in #76163), after which we will drop support entirely.
Activity
gabyhelp commentedon Apr 30, 2026
Related Issues
Related Code Changes
Related Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
mateusz834 commentedon Apr 30, 2026
Is that log needed? Like if it is already deprecated, it could just do nothing, right? I am just uncertain whether adding an stderr log is a good idea, since making
CancelRequesta noop is unlikely to break programs, but printing, might break some code.neild commentedon Apr 30, 2026
Failing to cancel a request that you expect to be canceled seems like it could cause problems.
If a program doesn't use
CancelRequest, the log is harmless.If it does use
CancelRequest(and we drop support forCancelRequest), it contains a bug; logging an error seems safer than panicking and more discoverable than silent failure.apparentlymart commentedon Apr 30, 2026
I agree that generating an unsolicited log line is a little risky because whether to use
log(vs various other possible logging strategies) is a cross-cutting decision that typically the entire program is expected to agree about.However, I also don't have any better ideas. I agree that silently doing nothing at all is more likely to cause real-world problems than sending a log line in a way that the rest of the program might not agree with. The unsolicited log output could potentially break CLI-based software whose caller relies on it generating output in a very specific format and fails otherwise, but that seems pretty narrow.
I don't know whether the runtime metrics for reliance on non-default GODEBUG are widely used in the ecosystem to detect this sort of thing, but for those who do use it I hope this would be implemented in a way that means each call to
CancelRequestwould increment the relevant metric if the GODEBUGhttptransportcancelrequest=1were set.calebrogers066-glitch commentedon Apr 30, 2026
aclements commentedon Jun 18, 2026
This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group
aclements commentedon Jul 1, 2026
Proposal review discussion
aclements commentedon Jul 8, 2026
Proposal review discussion
aclements commentedon Jul 8, 2026
Based on the discussion above, this proposal seems like a likely accept.
— aclements for the proposal review group
The proposal is given in #79040 (comment)
6 remaining items
gopherbot commentedon Jul 21, 2026
Change https://go.dev/cl/803840 mentions this issue:
net/http: make Transport.CancelRequest into a no-opnet/http: make Transport.CancelRequest into a no-op
prattmic commentedon Sep 24, 2026
What became of the
httptransportcancelrequestGODEBUG tied to the language version that controls this feature?neild commentedon Sep 24, 2026
Apparently I completely forgot it because I am not very smart. Will fix, sorry.