-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: listening on a local port for a test requires tedious boilerplate #24778
Comments
I presume there's a reason to not use |
...oh, net.Listen requires that you specify "tcp" or "tcp6". That would be the reason. :) |
Perhaps in the spirit of https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06 we should special case a lookup of "localhost" when the network is "tcp" (not "tcp4" or "tcp6") and just do the right thing, rather than adding any new API. That is, if your system's DNS says that "localhost" is "127.0.0.1" and you're on an IPv6-only system, then Go shouldn't care about your DNS value if you say |
Even without special casing, I believe "localhost" should do the right thing on any properly configured system. My (My previous comment about "tcp" vs. "tcp6" is wrong; "tcp" happily resolves either v4 or v6 addresses.) |
My proposal is we let localhost be localhost regardless of their config. |
Closing as dup of #22826 but it seems like a good idea, provided we can get some insight into how close the draft is to being an RFC. Note that the draft in this issue is from August 2017 while the draft in the other issue is newer, from December 2017. |
#22826 (let localhost be localhost) SGTM, but I think it's reasonable to use |
In the stdlib alone, there are 6 functions called
newLocalListener
that do something roughly like(there are admittedly differences in between them in how they handle errors, etc)
It would be nice (for consumers of the stdlib as well) if there was an easy way to do this with one line.
You might think that listening on the unspecified interface would help, but there are two downsides. First, you might not want your test server to be externally accessible! Second, if you listen on the unspecified interface then your listener.Addr() is like "0.0.0.0" or "::" which you may not be able to connect to in all environments (and you may run into issues like #24737 as well).
(Arguably this would go well in a net/nettest package like net/http/httptest, but that isn't a thing.)
The text was updated successfully, but these errors were encountered: