Conversation
jimlambrt
force-pushed
the
jimlambrt-validate-addr
branch
3 times, most recently
from
ade9264 to
cf9e02d
Compare
Add validation to the addr parameter of Server.Run(...) to ensure it is a valid TCP address. If the addr is ipv6, and it's missing the required square brackets, add them.
jimlambrt
force-pushed
the
jimlambrt-validate-addr
branch
from
cf9e02d to
2b5fa2c
Compare
server.go
Outdated
| } | ||
|
|
||
| // see if we're dealing with a hostname | ||
| hostnames, _ := net.LookupHost(rawHost) |
There was a problem hiding this comment.
This triggers a DNS lookup and may be slow or may have unexpected consequences. I suggest netip.ParseAddr and see if there is an error.
There was a problem hiding this comment.
Hum... I converted to resolver.LookupHost(...) so I can add a timeout which will alievate some of the issues.
the point of looking up the host it to ensure we have an IP after this lookup which the rest of the func relies on.
There was a problem hiding this comment.
Ah. I thought that the point was to discover whether or not it's an IP address -- not that you needed an IP address at the end of the function...since Dial will do that resolution for you.
There was a problem hiding this comment.
If it's ipv6, we sort of "need" a proper literal IP (if it's an IP) otherwise the Listen(...) will fail. Besides trying to form a proper literal ipv6, we're validating that addr is indeed something that we can pass along to the Listen(...) call.
At this point, we want to resolve the hostname if needed, so we can rely on the fact that we're mucking around with an IP for the rest of the func.
|
LGTM but the discussion was marked Outdated so I'm not sure you got notified about my comment: #63 (comment) If I'm wrong about that then no worries. |
2 participants
Add validation to the addr parameter of
Server.Run(...) to ensure it is a valid TCP
address. If the addr is ipv6, and it's missing
the required square brackets, add them.