You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to me if I can get access to the underlying connections in a response object. I only want to do some read-only introspection (I'm aware that actually reading/writing from the conns would be rather dangerous).
It is fairly trivial to do this in a way that won't break backwards compatibility by introducing an optional interface that can be satisfied with one or two functions (depending on if it's one function for tcp and one for udp or if the same function returns both). I've tested this locally and it's a very small change that works well.
Would this be something that would be accepted in a PR? If not, is there another way to get the connection related to an incoming message?
Thanks!
The text was updated successfully, but these errors were encountered:
crypto/tls has let you do this since go1.18 so it doesn't seem like the worst idea (https://pkg.go.dev/crypto/tls#Conn.NetConn). Though they have the benefit of always having a TCP connection (except when using QUIC).
Out of interest, what in particular are you trying to get from the underlying connection?
For more explanation: some platforms (cough, Windows, cough) do not allow you to firewall anything on localhost so if you want to perform any introspection or security controls you have to do it yourself, so having connection information is extremely useful.
Hello, and thanks for a great library!
It would be useful to me if I can get access to the underlying connections in a
response
object. I only want to do some read-only introspection (I'm aware that actually reading/writing from the conns would be rather dangerous).It is fairly trivial to do this in a way that won't break backwards compatibility by introducing an optional interface that can be satisfied with one or two functions (depending on if it's one function for
tcp
and one forudp
or if the same function returns both). I've tested this locally and it's a very small change that works well.Would this be something that would be accepted in a PR? If not, is there another way to get the connection related to an incoming message?
Thanks!
The text was updated successfully, but these errors were encountered: