generic support for endpoint URIs using unix:// scheme

[jdef]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

several sinks and sources support "endpoint" and "address" parameters, which are fed into the http client. but I don't see where non-standard schemes are supported by the client. i'd like to use vector to push metrics through unix domain sockets using the existing sink connectors, but very few sinks support a "mode" property (that allows one to pick "unix").

ideally, I'd be able to configure any sink "endpoint" property with a value like unix:///path/to/unix.sock and the http client would do the right thing.

Attempted Solutions

No response

Proposal

No response

References

No response

Version

No response

[weriomat]

This is an issue I ran into while implementing a solution for #5794. There is now an HTTP client that can connect over Unix sockets, making this a good step in the right direction.
One question I have is how a path in the URI can be given. To explain my problem more clearly, we have a connection string like the following: http://localhost/some/random/endpoint. This would be parsed as scheme: http; host: localhost; path: /some/random/endpoint. On the other hand, how can this be decided for a URI with a Unix socket? In this case, we have the following URI: unix:///var/run/someservice/service.sock/some/random/endpoint. How can the host part (/var/run/someservice/service.sock) be differentiated from the path /some/random/endpoint?
There are three solutions from what I have gathered.
The first is to have one argument for the Unix socket path and another argument for the path in the URI (i.e., in hyperlocal). The implementation would involve a custom wrapper around the String type with an untagged union. A prototype for this is implemented in #25095.
The second is to escape the path to the Unix socket with the URL escape code %2F. This is not possible, as we use Hyperium’s HTTP crate (ref. here and here).
The last option is to pass the path to the Unix socket as a query parameter (i.e., unix://some-random-host-for-parser-correctivness/some/random/endpoint?host=/var/run/someservice/service.sock). This is done by PostgreSQL see 31.1.1.2. Connection URIs. The downside is that if there is a host parameter required by the underlying service, this approach cannot be taken. The implementation would involve a custom “parser” for the URI where unix schemes would be transformed like hyperlocal does it.
Any feedback on which approach is preferred?

[pront]

Hi @weriomat, thanks for the detailed write up!

Regarding URI disambiguation question: the "two separate config arguments" is the most explicit and least surprising for users IMO. It avoids any URI parsing ambiguity . The socket source and sink socket source use a mode enum with a separate path field for the socket. The downside is it doesn't give us a single unified URI string.

Right now PR #25095 adds Unix socket support specifically to prometheus_scrape via a new UnixHttpClient that largely duplicates HttpClient. The original ask in this issue is for generic unix:// support across all HTTP-based components (http sink, datadog, prometheus remote write, splunk, loki, clickhouse, etc.).

Where this support should live though? Probably in the connector layer inside HttpClient itself (src/http.rs).

[weriomat]

@pront thank you for your quick response.
Currently, #25095 implements a solution for your choice of parsing the URI. Could you take a look at that specific part of the PR? If it is sufficient, I would factor that out to a general place.
Furthermore, I agree that there is no unified solution and that there is a limitation of the URI in combination with Unix sockets...

Regarding the code duplication from the HttpClient: as you can see, the type HttpProxyConnector = ProxyConnector<HttpsConnector<HttpConnector>>; mentions the HttpConnector, which expects the underlying transport layer to be a non-Unix-socket connection and therefore cannot be used by "users" of the HttpClient. Making the HttpClient generic over the HttpProxyConnector could be a solution but would require a significant rewrite of src/http.rs and the surrounding infrastructure (and possibly the TLS/proxy settings within each source).
The easiest to implement would be to have a separate client for Unix connections. The resulting downside is that each source would have to handle the parsing of the URI and Unix connections separately with the UnixHttpClient. As you saw, I already took a shot at implementing this feature.
As we are currently using hyper 0.14, it could be an idea to upgrade to 1.x and use the Client, as it takes a reference to a Stream of some kind (i.e., TcpStream/UnixStream from tokio::net). Once again, this requires a significant rewrite and would not be compatible with, e.g., hyper_proxy (which, in itself, has not received any updates for five years...).
Another solution would be to refactor everything and use the reqwest library (which includes HTTP proxying mechanics and TLS integration). That would, IMO, be the best path to take but would also require a significant rewrite.
Regarding an implementation, I can definitely help, but as this alters a crucial component of Vector, I would not like to undertake such a transformation alone.

Lastly, every source would have to be altered to take the new URI enum and handle Unix sockets. I cannot test each source with Unix sockets, as I do not have the time or the services running...