Unable to disable keep-alive in http server

[gopherbot]

by thomas.intlayer:

If you use http.ListenAndServe() to create a simple HTTP server, you have no way to
force non-keep-alive responses to clients who request keep-alive.

ResponseWriter does not have a Close field and setting a "Connection: close"
header does to work either.
Setting Request.Close to true does not help aswell.

The bug gets bad as serve() in server.go loops one more time because w.closeAfterReply
is false, trying to read another request even if the client is gone which in turn can
take a long time since the default read and write timeouts are set to 0 aka infinity.
This is a problem for server that need to close connections right away or otherwise end
up exhausting file descriptors.

There is a dirty hack to force closing of connections:
send a Connection: close header and overwrite w.ProtoMinor with 0.
This works as HTTP/1.0 does not do keep-alive by default and the Go code will set
w.closeAfterReply to true internally. It might have sideeffects which I did not explore
so be aware!


PS: I would even consider it a security issue that you can't forcefully close
connections as this leaves the server open for trivial DoS attacks.
Though I do not see how this can be completely fixed without some major changes in how
the http package works (you need non-blocking or curl-style callback (to measure
transfer speed) functionality to combat Slowloris for example)


Suggested fixes:
- expose a method to close client connections forcefully, maybe expose ClientConn to the
server
- set w.closeAfterReply if (to be added) w.Close is true or "Connection:
close" header exists
- set default read and write timeouts to something like 300 seconds

[gopherbot]

Comment 1 by thomas.intlayer:

Typo: it should have been Request.ProtoMinor, not w.ProtoMinor

[rsc]

Comment 2:

Maybe Header().Set("Connection", "close") should be honored?

Owner changed to @bradfitz.

[bradfitz]

Comment 3:

Labels changed: added pkg-http.

[bradfitz]

Comment 4:

This issue was closed by revision ac213ab.

Status changed to Fixed.

[bradfitz]

Comment 5:

This is now fixed, but note that you could previously also Hijack the connection (the
ResponseWriter is a http.Hijacker) and then close it.

[gopherbot]

Comment 6 by thomas.intlayer:

Brad: it seems that you can Hijack() the connection but for that you have to type cast
the ResponseWriter to a http.Hijacker, not very straight forward.

[adg]

Comment 7:

That's by design. It means that anyone who wants to implement the http.ResponseWriter
needn't implement Hijack.

[gopherbot]

Comment 8 by thomas.intlayer:

How does one find out if a ResponseWriter implements Hijack without reading the
sourcecode (server.go here?
In this example, the ResponseWriter passed to handlers is in fact a http.response which
is not exported and therefor not in the docs.

[bradfitz]

Comment 9:

It's documented: http://golang.org/pkg/http/#Hijacker
You test for it at runtime.  App Engine doesn't support Hijacking, but the Go http
package does:
if hj, ok := rw.(http.Hijacker); ok {
    // ...
}

[gopherbot]

Comment 10 by thomas.intlayer:

From what I understand, it only says that some ResponseWriters may implement the
Hijacker interface.
"The Hijacker interface is implemented by ResponseWriters that allow an HTTP handler to
take over the connection."
It does not say that the ResponseWriter passed to the handler func from ListenAndServe
implements Hijacker.