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: Request.Body locking should be interruptable on Close #7121

Closed
bradfitz opened this issue Jan 14, 2014 · 9 comments
Closed

net/http: Request.Body locking should be interruptable on Close #7121

bradfitz opened this issue Jan 14, 2014 · 9 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bradfitz
Copy link
Contributor

The fix to issue #6995 made me realize that the new locking introduced in revision
00cce3a34d7eSimilar is too coarse.

It's now possible for a goroutine outside of the main server handler goroutine to be
blocked in a Request.Body.Read (a transfer.go *body.Read) indefinitely, holding the
*body mutex.

That mutex then prevents the server code from closing that body when the handler
completes.

Similar to how an io.Pipe's PipeReader.Read will be interrupted when the pipe is closed,
I think the http server's Request.Body.Read needs to be interruptable.  Perhaps it
should just use io.Pipe somewhere.


Example test showing the problem:

// Test that a hanging Request.Body.Read from another goroutine can't
// cause the Handler goroutine's Request.Body.Close to block.
// See golang.org/issue/7121
func TestRequestBodyCloseDoesntBlock(t *testing.T) {
        if testing.Short() {
                t.Skip("skipping in -short mode")
        }
        defer afterTest(t)

        readErrCh := make(chan error, 1)
        errCh := make(chan error, 2)

        server := httptest.NewServer(HandlerFunc(func(rw ResponseWriter, req *Request) {
                go func(body io.Reader) {
            _, err := body.Read(make([]byte, 100))
                        readErrCh <- err
            }(req.Body)
        time.Sleep(500 * time.Millisecond)
        }))
        defer server.Close()

    closeConn := make(chan bool)
        defer close(closeConn)
        go func() {
                conn, err := net.Dial("tcp", server.Listener.Addr().String())
                if err != nil {
            errCh <- err
                        return
            }
                defer conn.Close()
        _, err = conn.Write([]byte("POST / HTTP/1.1\r\nConnection: close\r\nHost: foo\r\nContent-Length: 100000\r\n\r\n"))
                if err != nil {
                        errCh <- err
                        return
        }
                // And now just block, making the server block on our
                // 100000 bytes of body that will never arrive.
                <-closeConn
        }()
        select {
    case err := <-readErrCh:
                t.Logf("Read error = %v", err)
        case err := <-errCh:
                t.Error(err)
    case <-time.After(5 * time.Second):
                t.Error("timeout")
        }
}
@bradfitz
Copy link
Contributor Author

Comment 1:

This issue was updated by revision 35710ee.

R=golang-codereviews, gobot, dsymonds
CC=golang-codereviews
https://golang.org/cl/51750044

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 2:

Brad, what's left?

@bradfitz
Copy link
Contributor Author

bradfitz commented Apr 3, 2014

Comment 3:

Too invasive and doesn't matter enough for Go 1.3. Very rare/odd case. Bumping to Go 1.4.

Labels changed: added release-go1.4, removed release-go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Sep 16, 2014

Comment 4:

Bumping to Go-None.

Labels changed: added release-none, removed release-go1.4.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@luna-duclos
Copy link

Are there any plans to fix this ?

When streaming data from the client, this makes it impossible to stop the streaming from the server side.

@bradfitz bradfitz modified the milestones: Go1.8Maybe, Unplanned Sep 29, 2016
@bradfitz bradfitz self-assigned this Sep 29, 2016
@bradfitz
Copy link
Contributor Author

I had forgotten about this. I put it on my list to investigate for Go 1.8.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 10, 2016
@rsc rsc modified the milestones: Go1.9, Go1.8Maybe Oct 20, 2016
@odeke-em
Copy link
Member

odeke-em commented Feb 5, 2017

@bradfitz seems like it passes now, unless am missing something. Running on tip

$ go version
go version devel +b53f0f8 Sat Feb 4 16:46:11 2017 +0000 darwin/amd64

with the code you provided in the bug report ie also at https://github.com/odeke-em/bugs/blob/master/golang/7121/issue_test.go with just defer afterTest commented
the test passes but prints out

$ go test -v
=== RUN   TestRequestBodyCloseDoesntBlock
--- PASS: TestRequestBodyCloseDoesntBlock (0.50s)
	issue_test.go:54: Read error = read tcp 127.0.0.1:60113->127.0.0.1:60114: i/o timeout
PASS
ok  	_/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/7121	0.513s

@gopherbot
Copy link

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

@odeke-em
Copy link
Member

I have traced back the fixer to be commit faf882d or CL https://go-review.googlesource.com/c/31173/.

Am finna enable the previously skipped test with a CL in a few.

@golang golang locked and limited conversation to collaborators Apr 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants