net/http: data race reading a "Expect: 100-Continue" request while writing response

[linkdata]

The goroutine reading the request body will be updating "ecr.sawEOF", while the goroutine writing the response will be reading that boolean with no synchronization.

Using go1.5.1 windows/amd64.

WARNING: DATA RACE
Read by goroutine 438:
  net/http.(*chunkWriter).writeHeader()
      C:/workdir/go/src/net/http/server.go:866 +0xe38
  net/http.(*chunkWriter).Write()
      C:/workdir/go/src/net/http/server.go:261 +0xbf
  bufio.(*Writer).Write()
      C:/workdir/go/src/bufio/bufio.go:594 +0x17b
  net/http.(*response).write()
      C:/workdir/go/src/net/http/server.go:1140 +0x316
  net/http.(*response).Write()
      C:/workdir/go/src/net/http/server.go:1112 +0x7f
  (...app...)

Previous write by goroutine 870:
  net/http.(*expectContinueReader).Read()
      C:/workdir/go/src/net/http/server.go:571 +0x351
  (...app...)

[ianlancetaylor]

CC @bradfitz

[bradfitz]

Unlike the client code, the net/http Server code does not use different goroutines for reading vs. writing.

Your Handler runs in the same goroutine that is reading the request (and request body) and writing the response (and response body).

Can you share your code or a minimal repro?

Are you using TimeoutHandler perhaps?

[linkdata]

The handler spawns a goroutine extra in order to handle streaming in a
proxy server, where alternating between reading and writing was difficult.
I realize that this violates the RFCs and I should Hijack() instead of
abusing http.Server. Possibly you might have a situation where a POST is
incoming while an error response is being written from another goroutine,
but that was not my use case. I since have worked around that race.

[bradfitz]

We should probably document the status quo for the past 5 years, that http.Handler's ResponseWriter should be written to from the same goroutine that that ServeHTTP was called from.

[rsc]

I don't think the specific goroutine matters. What matters is that the ResponseWriter must not be written to after the handler returns.

[gopherbot]

CL https://golang.org/cl/17982 mentions this issue.