Repository navigation
crypto/tls: allow access to net.Conn underneath tls.Conn #29257
Description
Currently it is not possible to access FD in tls.Conn
in tls.Conn the underlying net.Conn is not accessible except in ClientHelloInfo
Senario:
in net/http we can't access the FD for https connections but we can access it for http connections
in a WebSocket connection after Hijack, when the connection is http we can use netpoll but when its https we can't
the only workaround right now is using a https to http proxy but it's not efficient as exposing the net.Conn on tls.Conn
/cc @FiloSottile
Reacted by Leo Antunes and Chaos
Activity
ja-nixi commentedon Dec 17, 2018
/cc @bradfitz
bradfitz commentedon Dec 17, 2018
/cc @ianlancetaylor
[-]crypto/tls: allow access to file descriptor for tls.Conn[/-][+]proposal: crypto/tls: allow access to file descriptor for tls.Conn[/+]odeke-em commentedon Mar 7, 2019
I have marked this as a proposal for it to get the proposal treatment.
ianlancetaylor commentedon Mar 20, 2019
What do you actually want to do with the file descriptor?
gopherbot commentedon Apr 20, 2019
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
blakerouse commentedon Jun 1, 2019
It is useful to get the underlying connections file descriptor so that it can be passed into a syscall for epoll. This removes the needed to start a go routine for every websocket connection.
In my concurrent-websocket module I need to do just that so multiple websocket connections can be multiplexed through a pool of goroutines. I am currently working around this issue by using reflect and unsafe, which is really bad!
L26 below shows how I am getting the connection, and you can see on L45 how I pass that connection to
netpoll.HandleReadOnce. It still uses thetls.Connfor reading and writing, but needs to pass the underlying connection for epoll to work.https://github.com/blakerouse/concurrent-websocket/blob/master/channel.go#L26
BernhardValenti commentedon Feb 4, 2020
This is also an issue when using TLS with the new
http.ServerConnContextcallback, in my case I want to get syscall.TCPInfo for each connection.45 remaining items
rsc commentedon May 12, 2021
No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
[-]proposal: crypto/tls: allow access to net.Conn underneath tls.Conn[/-][+]crypto/tls: allow access to net.Conn underneath tls.Conn[/+]jarrettyeo commentedon May 19, 2021
@rsc Thank you for fixing this, when will this issue be resolved?
gopherbot commentedon Jun 5, 2021
Change https://golang.org/cl/325250 mentions this issue:
crypto/tls: add NetConn methodTry and add a listener implementation
crypto/tls: add Conn.NetConn method