Skip to content
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

unix domain socket support? #538

Closed
futurist opened this issue Aug 31, 2022 · 9 comments
Closed

unix domain socket support? #538

futurist opened this issue Aug 31, 2022 · 9 comments

Comments

@futurist
Copy link

Don't find in the docs about unix domain socket support. Can provider an example for this?

@samuelallan72
Copy link

Does ureq support unix domain sockets?

@jsha
Copy link
Collaborator

jsha commented Oct 6, 2023

Not currently, no.

@cablehead
Copy link

With ureq's focus on simplicity, do you think there'd be interest in accepting a PR to add unix domain socket support?

@algesten
Copy link
Owner

What would the API look like?

@samuelallan72
Copy link

Some initial ideas:

Add a transport type to the agent:

let agent = ureq::AgentBuilder::new()
    .transport(ureq::TransportType::UnixSocket("/var/snap/lxd/common/lxd-user/unix.socket"))
    .build();

// This is sent over the socket.
let resp = agent.get("http://lxd/1.0/instances").call()?;

Allow setting a raw transport stream (eg. maybe anything that implements Read and Write) to read and write from in the agent:

let agent = ureq::AgentBuilder::new()
    .transport(std::os::unix::net::UnixStream::connect("/var/snap/lxd/common/lxd-user/unix.socket"))
    .build();

// This is sent over the socket.
let resp = agent.get("http://lxd/1.0/instances").call()?;

Embed the socket in the protocol string somehow (note: there is no standard for this yet - see whatwg/url#577 ):

ureq::get("unix:/var/snap/lxd/common/lxd-user/unix.socket:http://lxd/1.0/instances").call()?;

@cablehead
Copy link

cablehead commented Mar 12, 2024

Adding to the mix of ideas, allow for ureq::get(paths in the form:

http+unix://%2Ftmp%2Fapi.sock/service?query=1
  • scheme: http+unix://, this allows https to still be conveniently expressed
  • authority: %2Ftmp%2Fapi.sock, sock path, requires the path to be URL encoded
  • path: /service?query=1

ureq would make configuring the underlying transport transparent to the caller here: https://github.com/algesten/ureq/blob/main/src/unit.rs#L369-L375

@algesten
Copy link
Owner

Closing since we're moving to ureq 3.x. In 3.x the transport is completely replaceable. This should be very solvable.

@MggMuggins
Copy link

I gave this a try with 3.0.0-rc2 and ran into issues parsing http+unix URIs with the http crate. It currently does not support percent-encoded host components. I might take a look at implementing the requested checks but right now it doesn't look like any of the suggested syntaxes are viable.

Even if http would merge support for percent-encoded URIs, ureq still needs to add a proto:

diff --git a/src/proxy.rs b/src/proxy.rs
index 7694713..8b771c2 100644
--- a/src/proxy.rs
+++ b/src/proxy.rs
@@ -23,6 +23,7 @@ pub(crate) enum Proto {
     Socks4,
     Socks4A,
     Socks5,
+    Unix,
 }
 
 impl Proto {
@@ -31,6 +32,7 @@ impl Proto {
             Proto::Http => 80,
             Proto::Https => 443,
             Proto::Socks4 | Proto::Socks4A | Proto::Socks5 => 1080,
+            Proto::Unix => u16::MAX,
         }
     }
 
@@ -279,6 +281,7 @@ impl TryFrom<&str> for Proto {
             "socks4a" => Ok(Proto::Socks4A),
             "socks" => Ok(Proto::Socks5),
             "socks5" => Ok(Proto::Socks5),
+            "http+unix" => Ok(Proto::Unix),
             _ => Err(Error::InvalidProxyUrl),
         }
     }
@@ -302,6 +305,7 @@ impl fmt::Display for Proto {
             Proto::Socks4 => write!(f, "SOCKS4"),
             Proto::Socks4A => write!(f, "SOCKS4a"),
             Proto::Socks5 => write!(f, "SOCKS5"),
+            Proto::Unix => write!(f, "UNIX"),
         }
     }
 }

Can this be reopened? I'll see about updating that PR to http.

@MggMuggins
Copy link

MggMuggins commented Nov 9, 2024

To be clear, the above doesn't stop one implementing a Connector/Transport/Resolver that contains the socket path and just ignores the host part of the URI. But it would be convenient if ureq could make http+unix URIs "just work".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants