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: connection leak on panic #4050

Closed
anacrolix opened this issue Sep 6, 2012 · 9 comments
Closed

net/http: connection leak on panic #4050

anacrolix opened this issue Sep 6, 2012 · 9 comments
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Milestone

Comments

@anacrolix
Copy link
Contributor

Connections are not closed if panic(nil) occurs during net.http.(*conn).serve().

http://code.google.com/p/go/source/browse/src/pkg/net/http/server.go#596

Specifically this occurs in user code during handler.ServeHTTP().

http://code.google.com/p/go/source/browse/src/pkg/net/http/server.go#681
@bradfitz
Copy link
Contributor

Comment 1:

Owner changed to @bradfitz.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 2:

Labels changed: added priority-later, removed priority-triage.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 3:

Labels changed: added go1.1.

@shanemhansen
Copy link
Contributor

Comment 4:

Reading the source code for server.go, it seems reasonable to c.Close() in the defer and
remove c.Close() from the bottom of the function.
I suppose you could also just call c.Close() in the deferred function and at the bottom
of serve. The implementations seem safe to close twice.
Does one of these solutions sounds reasonable? I can go ahead and code it up.

@anacrolix
Copy link
Contributor Author

Comment 5:

I think it's worth fixing this ASAP. panic(nil) anywhere here (and particularly in
unpredictable user code) is silently discarded, and leaks connections. Of course, panics
being primarily used for exceptional cases means this doesn't happen often enough to be
noticeable for some time, which is even worse.
I'm not sure why c, and c.rwc are closed separately, and didn't bother to dig into it. I
think the easiest solution is to stuff:
defer func() {
    if !c.hijacked {
        c.close()
    }
}()
At line 617, and remove c.close() from line 704.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 6:

Labels changed: added size-m.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 7:

Labels changed: added suggested.

@bradfitz
Copy link
Contributor

Comment 8:

https://golang.org/cl/6971049

Status changed to Started.

@bradfitz
Copy link
Contributor

Comment 9:

This issue was closed by revision 91934ff.

Status changed to Fixed.

@anacrolix anacrolix added fixed Suggested Issues that may be good for new contributors looking for work to do. labels Dec 19, 2012
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Projects
None yet
Development

No branches or pull requests

5 participants