Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: document that it's illegal to reuse a Request concurrently from multiple goroutines #21780

twmb opened this issue Sep 6, 2017 · 10 comments


Copy link

@twmb twmb commented Sep 6, 2017

Incorrect errRequestCanceled errors occur when reusing http.Request structs.

There is a small race in reusing Transport's reqCanceler map, where a finishing request can override an active request dial's canceler. I suspect this is what #19653 was running into, and Brad hinted at this.

The problem:

The code centers around transport.go's RoundTrip block of code here, L400-L413.

For two requests a and b that execute back to back:
a sees a body's EOF: L1622-L1624,
b begins, enters RoundTrip, tries to getConn, no idle conns exist, b sets the request's canceler (L940, important), and a large select happens: L948-L986
a's persistConn running gets notified of the bodyEOF, sets its transport's request canceler for this request to nil (L1656) overriding the canceler that was just set by B, and goes to tryPutIdleConn (assuming other conditions are successful): L1655-L1661
a''s tryPutIdleConn sees a waitingDialer: L704-L706
b's dial select receives the persistConn that just ran a: L976-L986
b's RoundTrip getConn returns successfully and goes into pconn.roundTrip (L400-L413, the main block)
roundTrip tries to replace the transports request canceler for b with the persistConn's cancelRequest: L1889-L1891
replaceReqCancel fails because the prior replacement deleted the request from the transport's reqCanceler map, and if the request does not exist in the map, the canceler for it cannot be replaced: L856-L865
This causes roundTrip to return errRequestCanceled: L1893

Also note that this is only the http1 stack and is harder to notice against URLs that have redirects.

What version of Go are you using (go version)?

1.8.3, 1.9, tip

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build465265467=/tmp/go-build -gno-record-gcc-switches"

What did you do?
go test -bench . -benchtime 10s (should happen quickly)

What did you expect to see?

No panic.

What did you see instead?

A panic.

@andybons andybons added this to the Go1.11 milestone Mar 26, 2018
Copy link

@andybons andybons commented Mar 26, 2018

Copy link

@odeke-em odeke-em commented Apr 24, 2018

@twmb thank you for filling this issue!

I am currently at tip d4e936c

$ go version
go version devel +d4e936c Tue Apr 24 20:21:08 2018 +0000 darwin/amd64

and I can't reproduce this issue
screen shot 2018-04-24 at 4 52 23 pm

/cc @tombergan @bradfitz

Copy link
Contributor Author

@twmb twmb commented Apr 25, 2018

$ go version && go test -bench .
go version devel +be012e1e2e Wed Apr 25 00:36:09 2018 +0000 linux/amd64
my thinger 0xc0000b0000
goos: linux
goarch: amd64
BenchmarkDeadreq-4   	my thinger 0xc0000b0000
panic: Get net/http: request canceled

goroutine 10 [running]:
_/home/twmb/testing.chk(0x701720, 0xc00016a390)
	/home/twmb/testing/junk_test.go:14 +0x4a
	/home/twmb/testing/junk_test.go:27 +0xd1
testing.(*B).RunParallel.func1(0xc000134030, 0xc000134028, 0xc000134020, 0xc000001e00, 0xc00000c060)
	/home/twmb/go/go/src/testing/benchmark.go:623 +0x97
created by testing.(*B).RunParallel
	/home/twmb/go/go/src/testing/benchmark.go:616 +0x192
exit status 2
FAIL	_/home/twmb/testing	0.034s
Copy link

@odeke-em odeke-em commented Apr 25, 2018

Thanks for the check-in @twmb and run on Linux, apparently I am living in a bubble with my Darwin AMD64 environment.

Copy link
Contributor Author

@twmb twmb commented Apr 25, 2018

I'm curious how this could be different on Darwin because none of the race is Darwin specific, but I'd have to dig back in.

Copy link

@bradfitz bradfitz commented Jul 9, 2018

This bug's title ("when reusing requests") made me think this was about back-to-back serial re-use of Requests, but the description and repro above ( show that this is really about about concurrent use of the same request.

I suppose this could be made to work at least for GETs, but I'm not sure it's worth it. If it doesn't work for POSTs or things with bodies, I think I'd rather just document one consistent rule: that you can't use a Request concurrently by multiple goroutines.

@bradfitz bradfitz changed the title net/http: incorrect `errRequestCanceled` returns when reusing requests net/http: document that it's illegal to reuse a Request concurrently from multiple goroutines Jul 9, 2018
@bradfitz bradfitz added the NeedsFix label Jul 9, 2018
@bradfitz bradfitz self-assigned this Jul 9, 2018
Copy link
Contributor Author

@twmb twmb commented Jul 9, 2018

Changing the benchmark to be serial reproduces this for me as well:

func BenchmarkDeadreq(b *testing.B) {
	req, err := http.NewRequest("GET", "", nil)
	client := new(http.Client)
	for i := 0; i < b.N; i++ {
		resp, err := client.Do(req)
		go func() {
			_, err = io.Copy(ioutil.Discard, resp.Body)

As far as I can tell, this is more in line with reusing a request serially back-to-back.

Copy link

@bradfitz bradfitz commented Jul 9, 2018

That still looks concurrent to me. You're not done with the request+response pair by the time of your next Do call.

Copy link
Contributor Author

@twmb twmb commented Jul 9, 2018

Agreed, I was drafting a response along those lines. I would be fine with documentation that a request cannot be request until after the response body is closed.

Copy link

@gopherbot gopherbot commented Jul 9, 2018

Change mentions this issue: net/http: clarify when it's allowed to reuse a Request

@gopherbot gopherbot closed this in 9776d02 Jul 10, 2018
@golang golang locked and limited conversation to collaborators Jul 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants