-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Optional interface for a ResponseWriter to expose Conns #1487
Comments
Out of interest, what in particular are you trying to get from the underlying connection? |
So for what it's worth here's one way to slice it, although there are other ways it can be done (or with other naming) Basically I need access to retrieve the local/remote addresses of the connections. |
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. |
The interface can be used by DNS handlers to access the underlying TCP or UDP connection. This can be useful if more information is needed about the request, such as to what port it was made. Fixes miekg#1487
We can close this as the PR to implement it was rejected. |
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: