Hi Konstantin
Thanks for the reply - this is exactly what I needed! It even seems
like tls.Conn has a function NetConn that allows me to get my net.Conn
back again. So for anyone stumbling on this in the future, I think
this is the way to solve it:
* Make the customer TLS dialer dial a TCP connection to the HTTPS
server to get a net.Conn
* Wrap the net.Conn in a custom struct like
type myConn struct {
net.Conn
myInfo myType
}
* Upgrade myConn to a tls.Conn by using the function tls.Client.
* Optionally perform the TLS handshake by calling Handshake or
HandshakeContext on the tls.Conn
* Return the tls.Conn from the dialer
* When a net.Conn is received from GotConn, cast it to tls.Conn, call
NetConn on the result, and cast that to myConn in order to access
myInfo.
Best
Christian
On Tue, Oct 25, 2022 at 1:57 PM Konstantin Khomoutov <kos...@bswap.ru> wrote:
>
> On Tue, Oct 25, 2022 at 03:43:21PM +0400, Konstantin Khomoutov wrote:
>
> >> However, that does not work well for TLS. The reason is that the Go HTTP
> >> client has special logic in case a custom dialer returns a *tls.Conn. That
> >> logic will be disabled.
> >
> > The Conn funtion of the crypto/tls package allows to "upgrade" a
> > user-supplied
>
> The function is called Client, sorry for the confusion.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAFu8dVoKAtTTj9QUxmfRjEzu60s6n9_SHfe203YuRk5LOiMWRw%40mail.gmail.com.
