fix(rpc): cross-platform support for /unix/ socket maddrs in Addresses.API#10019
Merged
Conversation
3 tasks
Contributor
Author
|
Some other commit was causing a conflict with the import statements, so I rebased and force pushed. No changes to the actual code in this PR though. |
gammazero
approved these changes
Aug 20, 2024
djdv
commented
Aug 20, 2024
NewApi
djdv
commented
Aug 20, 2024
Co-authored-by: djdv <ddvpublic@Gmail.com>
lidel
approved these changes
Aug 20, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
closes: #10018
This simply removes the need to dial the domain by specifying the dialer in the transport.
And removes any concerns in regards to the socket's path containing characters that are not valid HTTP URLs.
We make requests to a made up domain
http://unixwhich the client is happy to engage with.There may be a better way to do this but I couldn't figure one out.
I considered trying to avoid calling
manet.DialArgssince it will be called twice for non-UDS maddrs (once here and again inNewApiWithClient).But if we do something like
multiaddr.ValueForProtocol(multiaddr.P_UNIX), this will cause issues on platforms like Windows.This is because multiaddr requires
/delimiters (/unix/C:/somewhere), whilenet.Dialand the OS wantC:\somewhere.ValueForProtocolwill returnC:/somewherewhilemanet.DialArgsreturnsC:\somewhere.So I just stuck with
manet.Dial.As an aside, I don't really understand why
NewApiWithClientis converting from a multiaddr, to a string, then back to a multiaddr. But this is out of scope.