Commit 902f8d9c authored by Russ Cox's avatar Russ Cox

net/http/httptest: fix deadlock in TestIssue7264

I am seeing deadlocks waiting on <-inHandler.
It seems to me that there is no guarantee that the
handler actually runs, if the client does

        write header
        close connection

fast enough. The server might see the EOF on the
connection before it manages to invoke the handler.

This change fixes the deadlock, but it may make
the test not actually test anything. Not sure.

LGTM=bradfitz
R=bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/140970043
parent b4bfa6c9
......@@ -32,10 +32,7 @@ func TestServer(t *testing.T) {
func TestIssue7264(t *testing.T) {
for i := 0; i < 1000; i++ {
func() {
inHandler := make(chan bool, 1)
ts := NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
inHandler <- true
}))
ts := NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {}))
defer ts.Close()
tr := &http.Transport{
ResponseHeaderTimeout: time.Nanosecond,
......@@ -43,7 +40,10 @@ func TestIssue7264(t *testing.T) {
defer tr.CloseIdleConnections()
c := &http.Client{Transport: tr}
res, err := c.Get(ts.URL)
<-inHandler
// err can be non-nil here.
// If the client writes the header and then immediately observes
// the timeout and closes the connection, the server might never
// have gotten a chance to send a response. That's okay.
if err == nil {
res.Body.Close()
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment