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.

Sign up for GitHub

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

Jump to bottom

[Feature Request] Upstream Proxy #51

Open
roniemartinez opened this issue Mar 29, 2023 · 9 comments
Open

[Feature Request] Upstream Proxy #51

roniemartinez opened this issue Mar 29, 2023 · 9 comments

Comments

@roniemartinez
Copy link

roniemartinez commented Mar 29, 2023 •
edited

I noticed that this crate supports upstream proxy before in b7a2136

But it was removed in 408999b

This is a very useful feature and might be worth it to bring it back?

I would like to propose a more flexible design instead of the original implementation by adding this to HttpHandler which will give an option to route traffic based on request or rotate from a list of upstream proxies

pub trait HttpHandler: Clone + Send + Sync + 'static {

    async fn get_upstream_proxy(&mut self, _ctx: &HttpContext, _req: &Request<Body>) -> String {
       // return upstream URL string here
    }
}
@omjadas
Copy link
Owner

omjadas commented Apr 8, 2023

The reason that I removed the initial upstream proxy implementation was because it did not work for websockets. If I can figure out a way that works for both HTTP and websockets, then I would be happy to include it as an implementation. I do like the idea of integrating the upstream proxy config with the HttpHandler.

@roniemartinez
Copy link
Author

This blog could be of interest as a reference since Hudsucker already uses tungstenite.

We could start with normal HTTP proxy support w/o websockets and make it optional with a flag similar to should_intercept.

@maxmindlin
Copy link

maxmindlin commented Feb 2, 2024 •
edited

+1 on the upstream proxy being useful for normal HTTP requests. I was going to implement this on my own (now with that git commit as reference), is there any other reference code or workaround thats useful in the meantime?

@roniemartinez
Copy link
Author

Going back to the open Tungstenite issue, there seems to be another attempt in snapview/tungstenite-rs#406 (comment) earlier.

@maxmindlin
Copy link

maxmindlin commented Feb 2, 2024 •
edited

Thanks @roniemartinez , looking at the previous code for the http proxy I see they were using hyper-proxy. Thats also what I was attempting to use but it seems like it might not be actively maintained anymore. Do you know if its still the best way forward for an http upstream proxy?

@roniemartinez
Copy link
Author

roniemartinez commented Feb 3, 2024 •
edited

Not sure about other libraries, but currently hyper-proxy (HTTP) and hyper-socks2 (SOCKS) are the only libraries that work.

@timercrack
Copy link

The reason that I removed the initial upstream proxy implementation was because it did not work for websockets. If I can figure out a way that works for both HTTP and websockets, then I would be happy to include it as an implementation. I do like the idea of integrating the upstream proxy config with the HttpHandler.

Do you have a solution now? Like mitmproxy python implementation?

@omjadas
Copy link
Owner

omjadas commented May 10, 2024

Do you have a solution now? Like mitmproxy python implementation?

There isn't support built directly into this library, however, you can either provide a custom hyper client (potentially using hyper-proxy2) or forward the requests yourself in the handle_request method.

@timercrack
Copy link

Could you provide an example? How to forward https and ws to additional target in handle_request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@timercrack @roniemartinez @omjadas @maxmindlin