net/http: feature request: Expose underlying net.Conn in http.Handler for querying state.

[gopherbot]

by davidben@chromium.org:

This is a minor feature request. It would be nice if http.Handler exposed the underlying
net.Conn for consumers to query state from. It does expose the tls.ConnectionState, but
if you're using a custom net.Listener implementation, there doesn't seem to be a way to
correlate calls to the Handler with the net.Conn the net.Listener returned.

My particular use case is pointing the standard HTTP server at a fork of crypto/tls to
write demo servers for testing how clients respond to this or that broken server
behavior, where the HTTP server prints out TLS connection state. Since it's a fork of
crypto/tls with quirks patched in, http.Request.TLS isn't filled in. Writing a dummy
HTTP/1.0 server is easy enough, and there's also http.Hijacker, but it'd be nice to be
able to use the existing HTTP server implementation without having to either reimplement
the HTTP stack or hijack the socket and lose the standard socket reuse, etc., behavior.

[ianlancetaylor]

Comment 1:

We do have Hijack, and it's not clear to me that we need another mechanism.  It sounds
like a very special purpose application to want access to the net.Conn without hijacking
the connection.

Labels changed: added repo-main, release-none.

[bradfitz]

Comment 2:

Exposing the net.Conn is exposing too much. It would let the Handler do Read and Write,
but the handler may used via the SPDY or HTTP/2 protocol, and then letting Handlers try
to assume they're in HTTP/1.1 and read or write stuff to the socket would be buggy.
You can fork net/http if you need to do weird things, or you can propose a much more
fine-grained mechanism.

Status changed to WontFix.