Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reverts #51
I think the motivation of this change is to allow users of this library to connect to the
ipinfo.io
API using IPv6. Before this change only the IPv4 domain is used.In my opinion #51 did not improve the status-quo in the right way. A few thoughts:
lookup_v6
misleads users as to what it does. Because of the missing type information and documentation the name wrongly implies thatlookup(&str)
only works on IPv4 addresses whilelookup_v6(&str)
deals with IPv6 addresses. This is not true and is confusing.If we do want to give users more control over these kinds lower level decisions then I think we would be better off allowing the user to provide their own reqwest::Client. Then they can use local_address to bind to a particular local address.
Choice between using
lookup_v6
andlookup
methods should almost never be a compile time decision. When I compile my binary I do not know if it will be running in an IPv4 only, IPv6 only, or Both environment.On this note I think this change should be reworked. I would recommend making IPv4 vs IPv6 address choice transparent. Try to use v6 and then fallback to v4 after a connection failure.