tungstenite-rs
tungstenite-rs copied to clipboard
snapview
Is there any support for proxies?
I can only access the dest host on another machine by ssh. If I can access it via proxy, it will be much convenient. How can I do it for tungstenite?
Yes I can use it, but I have many different websocket addresses, so SSH TCP tunnelling is not very convenient.
We thought about making one of our internal libraries public (it brings support for proxies and supports such auth methods as basic, digest, ntlm, negotiate via SSPI / GSSAPI), but the support for proxies and their authentication methods should be part of another crate. We could introduce a proxy feature though that could rely on another crate for proxy and proxy authentication.
I actually believe we've discussed it somewhere in issues here, but can't find the discussion by just quick search for proxies (perhaps it was in one or another PR)
I created a branch that supports sock5 proxy in my forked repo, which may be helpful to you. pub fn connect_with_proxy
Actually I guess support for http/https proxy will be more useful. As I write in https://github.com/snapview/tokio-tungstenite/issues/168, to inspect secure websocket connections, the best way is to use some mitm proxy software, which requires the client to send domain (HTTP GET request) rather than resolved ip address. And BTW it also requires support for specifying custom CA certificate, to allow mitm work.
For client behind firewall and only proxy allowed, there are many workarounds, such as using gost to convert almost any proxy protocol to a transparent one, as long as one don't need to inspect the raw stream or the target is plain, unsecured websocket. Still crate level support is always better, for crate users.
Since we can use any stream that implementes Read and Write(or Async version), a proxy connection like async_socks5 would suffice.
Since we can use any stream that implementes Read and Write(or Async version), a proxy connection like async_socks5 would suffice.
I had a quick look at it and it seems like you can combine these easily, i.e. just use the async_sock5 to connect to the proxy and then pass the "upgraded" stream to the client() or something.
It would be great to support system proxies like reqwest does, which can be utilized by Docker easily without change the code.
Yes, it could have been more convenient, but reqwest is by its nature a batteries included wrapper around HTTP, whereas tungstenite-rs is more like a core for support of WebSockets with optional blocking implementation for quick/typical use cases. tungstenite-rs is more akin to hyper in this regard rather than to reqwest if I can put it like this.
@siegfried what makes them so "system"? Is HTTP_PROXY a standard well-known env var that a lot of software expects to be set systemwide?
@siegfried what makes them so "system"? Is
HTTP_PROXYa standard well-known env var that a lot of software expects to be set systemwide?
Supported by CURL, Docker, wget and reqwest. Call it "standard", "convention" or whatever you like. Not interested at the definition debate. I agree with what @application-developer-DA said.
so, any solution can solve the proxy problems?
@Praying depends on the type of proxy. Here's secure websocket over HTTPS proxy: https://github.com/websockets-rs/rust-websocket/issues/258#issuecomment-1052801655
In particular, since both that approach and async_socks5::connect leave you with an un-wrapped tokio::net::TcpSocket or whatever else you had, you can easily handle HTTP_PROXY values of http:// and socks5://, or lack thereof, without any dyn, enums, or generics.
Only what you do on the socket before passing it to tokio_tungstenite::client_async_tls changes!
FYI. I'm using async-http-proxy with async-tungstenite and works well for general HTTP proxy (not SOCK5). I remember that the feature was tested with nginx, squid, haproxy, and proxy.py
