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: feature request: Expose underlying net.Conn in http.Handler for querying state. #8957

Closed
gopherbot opened this issue Oct 18, 2014 · 2 comments

Comments

Projects
None yet
3 participants
@gopherbot
Copy link

commented Oct 18, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2014

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

This comment has been minimized.

Copy link
Member

commented Oct 18, 2014

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.

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.