Add support for HTTP proxies with optional Basic Authentication #55
Conversation
| // Add the trailing empty line | ||
| buf.extend_from_slice(b"\r\n"); | ||
|
|
||
| let _ = raw_stream.write(&buf)?; |
There was a problem hiding this comment.
I might need to continue in the for addr in addrs loop instead of early-returning here.
| let mut response_vec = Vec::with_capacity(1024); | ||
|
|
||
| loop { | ||
| let n = raw_stream.read(&mut read_buf)?; |
| let mut hbuffer = [httparse::EMPTY_HEADER; super::handshake::headers::MAX_HEADERS]; | ||
| let mut res = httparse::Response::new(&mut hbuffer); | ||
|
|
||
| match res.parse(&response_vec)? { |
|
Thank you. Our approach is to negotiate proxy connection separately and pass a socket to Tungstenite then. This does not require changes in Tungstenite. We use it with Tokio in production. |
That makes sense! As I mentioned, I wanted to do it that way but I felt like I was replicating a lot of the original tungstenite logic. Feel free to close this, but I would be very interested to hear if you ever open source the proxy support crate you mentioned. |
|
I'm currently checking some PRs to see which ones can be closed / merged. This one seems to be obsolete and conflicts with master. I'll close it, because it actually requires some deeper changes, i.e. "open-sourcing" our proxy support library and/or using some other libraries for that, so that |
|
Hello, any update on the proxy support library @application-developer-DA |
|
@metaclips unfortunately no updates here. We do have a proxy library which we have not open-sourced yet (it still requires some clean ups etc), we could theoretically publish it "as is" though. |
|
Please do. Thanks. |
I wrote a CLI application which is sometimes used behind corporate proxies. Although the HTTP client I'm using supports configuring a proxy, this library did not, so here I am.
It currently only supports HTTP proxies (not HTTPS or SOCKS though I imagine those would be fairly easy to add) and can optionally use Basic Auth for authentication.
Halfway through implementing, I realized there's a
clientfunction which allows you to pass in your ownRead + Writestream. I tried using it but found myself reimplementing a lot of what already exists inside this crate, especially theconnect_to_someandwrap_streamfunctions.If you feel this functionality is inappropriate to this crate and want to close this PR, that's totally okay! In that case I'll use our fork and be done with it. It just seemed like no WebSocket clients support this in an easy fashion. However I'm pretty new to interacting with proxy servers so perhaps there's a more obvious way to do what I want in these libraries (tungstenite, websocket-rs, etc.) without this change. If so, please let me know!