rpc: fix - Unix domain socket maddrs used with NewApi
#10019
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://unix
which 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.DialArgs
since 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.Dial
and the OS wantC:\somewhere
.ValueForProtocol
will returnC:/somewhere
whilemanet.DialArgs
returnsC:\somewhere
.So I just stuck with
manet.Dial
.As an aside, I don't really understand why
NewApiWithClient
is converting from a multiaddr, to a string, then back to a multiaddr. But this is out of scope.