From 902f8d9ca036974a853ade8efdd609434a19bbbe Mon Sep 17 00:00:00 2001 From: Russ Cox Date: Sun, 7 Sep 2014 20:13:35 -0400 Subject: [PATCH] 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 --- src/pkg/net/http/httptest/server_test.go | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/pkg/net/http/httptest/server_test.go b/src/pkg/net/http/httptest/server_test.go index 501cc8a999..a1c38c50ba 100644 --- a/src/pkg/net/http/httptest/server_test.go +++ b/src/pkg/net/http/httptest/server_test.go @@ -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() } -- 2.50.0