-
Notifications
You must be signed in to change notification settings - Fork 169
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
Handle connecting to ipv6 addresses correctly #386
Conversation
Previously, it would attempt to use the host from the url, which includes the `[]` which `to_socket_addrs()` didn't know how to deal with. This change strips the `[]`s. Fixes: nats-io#322 Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
@jszwedko thanks for taking the time and making this PR! We will look into it this week. |
@Jarema I'm sorry for the ping but any chance you could look into this soon? |
@gaffneyc of course, I will look into that tomorrow, sorry for the delay! |
@jszwedko I'm a little surprised by this, as docs clearly state:
https://docs.rs/url/latest/url/enum.Host.html so stripping should not be necessary. Could you please provide failing test or some more details? |
It's not a failing test case (as I don't know enough Rust to contribute one) but the simple program below from #322 shows the issue. // docker run --rm -ti -p 4223:4223 nats -p 4223 --user user --pass pass
fn main() {
let nc = nats::connect("nats://user:pass@[::1]:4223");
println!("{:#?}", nc);
} |
HI @Jarema ! Thanks for taking a look. It looks like Looking at RFC 5952 A Recommendation for IPv6 Address Text Representation this line jumped out to me:
Which makes me think that wrapping it in However, then looking at https://url.spec.whatwg.org/#host-parsing (linked from https://docs.rs/url/latest/url/enum.Host.html#method.parse) it specifically says:
So now I'm not sure 😄 Probably worth opening up an issue on the |
I guess the docs for
I still think it's a bit confusing though so I opened servo/rust-url#770 to get some clarity from the |
I'll get on this review just after implementing Pull Consumers (on it now). Saw your issue, but no response yet, so I guess we have to work around it. |
Can I help testing this somehow? Would solve a few ugly workarounds I have in place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After investigation, seems that docs are off and we have to remove the [] ourselves, so that validates this PR.
Some small changes are suggested, but one missing thing is:
Please add tests :). It is especially important in the context that it is a bug on rust-url
.
I would like to have this test failed when behaviour changes instead of getting unhappy users with broken clients.
If you need help with this let me know.
@@ -610,7 +610,15 @@ impl ServerAddress { | |||
|
|||
/// Returns the host. | |||
pub fn host(&self) -> &str { | |||
self.0.host_str().unwrap() | |||
match self.0.host() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if
with else
would be cleaner here.
Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
Thanks for taking a look @Jarema ! I pushed up some unit tests. Let me know if you were thinking of something else for testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
thank you for your contribution and patience!
Previously, it would attempt to use the host from the url, which
includes the
[]
whichto_socket_addrs()
used directly whenresolving which would cause it to fail to resolve. This change
change strips the
[]
s.Fixes: #322
Signed-off-by: Jesse Szwedko jesse@szwedko.me