felipenoris / hyper-reverse-proxy Goto Github PK

View Code? Open in Web Editor NEW

180.0 180.0 63.0 69 KB

A simple reverse proxy for use with Hyper and Tokio

License: Apache License 2.0

Rust 100.00%

async http http-proxy hyper reverse-proxy rust tokio

hyper-reverse-proxy's People

Contributors

Stargazers

Watchers

Forkers

jitendraky ameobea perseus101 nazgulsenpai atul9 mikelodder7 duzhanyuan jabdoa2 ironcorelabs ore3 ml-applications zhutony hnakamur thomaskes goiw111 nemo157 finnferra iojcde lazywalker jtroo amoghyermalkar123 daramir little-chili cibingeorge venryx iroco-co chesedo aeschli kokocares yu-re-ka myaats zhyi12 pymongo laik jmagnuson fauve-edf zys864 somehowchris ravenger icodein andrewsc208 tsingson mrostamipoor cryptidtech fransklaver ealui-statsig fwt11 pan-rui bsbds chpio chorusone tarrencev cameronbraid thearyanahmed hayathms louis-she

hyper-reverse-proxy's Issues

"Unsupported scheme http" when running the example.

Hello,

When running the example with the following dependencies :

[package]
name = "proxy_2"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
hyper-reverse-proxy = { git = "https://github.com/felipenoris/hyper-reverse-proxy", branch = "master" }
hyper = { version = "0.14.18", features = ["full"] }
tokio = { version = "1.18.2", features = ["full"] }
lazy_static = "1.4.0"
hyper-trust-dns = { version = "0.4.2", features = [
  "rustls-http2",
  "dnssec-ring",
  "dns-over-https-rustls",
  "rustls-webpki",
  "https-only"
] }

I get an ̀_error:HyperError(hyper::Error(Connect, Custom { kind: Other, error: "Unsupported scheme http" })) when proxying to a local http service. It seems to be related to hyper-trust-dns client, but removing the feature "https-only" does nothing...

Handle Trailers

Go's httputil.ReverseProxy handles Trailers. We currently don't. It would be a tricky thing to do because they need to be inserted after the body has been streamed. I'm not sure how to do it with hyper.

See reverseproxy.go for an example of how the go folks do it!

Example in readme fails to compile

I get the following error, when copying the readme's example verbatim into an .rs file:

the value of the associated type `Output` (from trait `futures_util::Future`) must be specifiedrustcE0191
gql_post.rs(6, 19): specify the associated type: `Future<Item=Response<Body>, Error=hyper::Error, Output = Type>`
trait objects must include the `dyn` keywordrustcE0782
gql_post.rs(6, 19): add `dyn` keyword before this trait: `dyn `

Screenshot:

Use the Forwarded header instead of X-Forwarded-For

Go's httputil.ReverseProxy uses the defacto standard of the X-Forwarded-For header, but I'm wondering if it would be better to use the standardised Forwarded header instead. Unfortunately it is not implemented in hyper yet, so we might have to do it ourselves, then try to upstream it.

cannot find trait `Connect` in module `hyper::client::connect`

hyper::client::connect::Connect seems rename to hyper::client::connect::Connected

ReverseProxy::new(hyper::Client::new())

   Compiling hyper-reverse-proxy v0.5.2-dev (https://github.com/felipenoris/hyper-reverse-proxy#102d50a0)
error[E0432]: unresolved import `hyper::Client`
   --> /home/w/.cargo/git/checkouts/hyper-reverse-proxy-d3515e9b5b577477/102d50a/src/lib.rs:118:19
    |
118 | use hyper::{Body, Client, Error, Request, Response, StatusCode};
    |                   ^^^^^^
    |                   |
    |                   no `Client` in the root
    |                   help: a similar name exists in the module (notice the capitalization): `client`

error[E0405]: cannot find trait `Connect` in module `hyper::client::connect`
   --> /home/w/.cargo/git/checkouts/hyper-reverse-proxy-d3515e9b5b577477/102d50a/src/lib.rs:389:50
    |
389 | pub async fn call<'a, T: hyper::client::connect::Connect + Clone + Send + Sync + 'static>(
    |                                                  ^^^^^^^ not found in `hyper::client::connect`

error[E0405]: cannot find trait `Connect` in module `hyper::client::connect`
   --> /home/w/.cargo/git/checkouts/hyper-reverse-proxy-d3515e9b5b577477/102d50a/src/lib.rs:455:52
    |
455 | pub struct ReverseProxy<T: hyper::client::connect::Connect + Clone + Send + Sync + 'static> {
    |                                                    ^^^^^^^ not found in `hyper::client::connect`

error[E0405]: cannot find trait `Connect` in module `hyper::client::connect`
   --> /home/w/.cargo/git/checkouts/hyper-reverse-proxy-d3515e9b5b577477/102d50a/src/lib.rs:459:33
    |
459 | impl<T: hyper::client::connect::Connect + Clone + Send + Sync + 'static> ReverseProxy<T> {
    |                                 ^^^^^^^ not found in `hyper::client::connect`

I'm maintaining a fork

Hi all, I've begun a fork of this project at the following repo: https://code.betamike.com/micropelago/hyper-reverse-proxy/

I've extended upstream with the following changes:

Fix for #53
Upgraded to hyper v1
Fixed some panics which can occur on a failed websocket upgrade

I'm not going to bother creating a new crates.io package for this or anything like that, if you'd like to use my fork you can do so by adding the following to your Cargo.toml:

[patch.crates-io]
hyper-reverse-proxy = { git = "https://code.betamike.com/micropelago/hyper-reverse-proxy.git", branch = "master" }

If you have any issues or patches with my fork you'd like me to be aware of please feel free to email me at the address in my GH profile.

Cheers!

Host header should not be set by reverse proxy

HRP is currently overwriting the Host header on the proxied request in all cases (see here). By doing so it makes it impossible for the caller to set its own Host header value.

This is breaking my use-case where I have a reverse-proxy downstream of HRP listening on http://[::1]:4080. The request being made by HRP ends up having Host: [::1], which is incorrect, and there's nothing I can do about it.

As far as I can tell there's no real reason for this header to be being added. The original issue, #18, mentions that it was done to match the go implementation, but if you check the link you'll see that the go implementation is rewriting the Host in the URL, not the header. If someone needs the header to match the proxy URL's host they can set it manually on their request, but I don't believe it should be forced.

I have a branch here where I removed the line which is adding the header (commit), and will be using it for my own projects. It would be great to get this upstreamed though, as it's a fairly severe bug I'd say.

(btw: is this project maintained anymore? It seems to have stalled out)

Custom error logging

We should allow folks to log failed requests in their preferred way, be it printf, slog, or something else...

Update the docs

Host rewrite

Hey :)

So I have been playing a bit around with this crate. Seems nice but some servers complain about SNI & Host header conflicts.

I couldn‘t see any code done to rewrite the host header. Did I miss something?

I‘m neither a go king but I think https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/net/http/httputil/reverseproxy.go;l=148 Is the part of go rewriting the host header

CI: build examples

Add action to build examples.

trailers are not preserved in responses

Hi there, great library!
I was reviewing this a little and found that hop-headers get removed from both requests and responses, but only requests put the trailers back in afterwards. I tried to compare this to the Go implementation, it is a bit hard to read, but it seems they also put the trailer back in.

Besides that, I saw that you have some unreleased changes on master. The newer API with the persistent client object is quite nice, do you plan to release this version?

Thank you!

Case issue when upgrading to websockets

Hello,

Thanks for this amazing crate.
I have an error when proxying ttyd : "backend tried to switch to protocol Some("WebSocket") when Some("websocket") was requested"... It would seems that converting all to lowercase like this :

fn get_upgrade_type(headers: &HeaderMap) -> Option<String> {
    if headers
        .get(&*CONNECTION_HEADER)
        .map(|value| {
            value
                .to_str()
                .unwrap()
                .split(',')
                .any(|e| e.trim().to_lowercase() == "upgrade")
        })
        .unwrap_or(false)
    {
        if let Some(upgrade_value) = headers.get(&*UPGRADE_HEADER) {
            debug!(
                "Found upgrade header with value: {}",
                upgrade_value.to_str().unwrap().to_owned()
            );

            return Some(upgrade_value.to_str().unwrap().to_lowercase().to_owned());
        }
    }

    None
}

would do the trick.

If it is OK for you I can make a PR, or let you change it directly, as convenient for you.

Best regards.

Jul 06 13:51:48 yaya rust-webserver[2689071]: thread 'tokio-runtime-worker' panicked at 'coping between upgraded connections failed: Kind(UnexpectedEof)', /build/cargo-vendor-dir/hyper-reverse-proxy-0.5.2-dev/src/lib.rs:425:26

cannot run test or bench on stable Rust

error[E0554]: `#![feature]` may not be used on the stable release channel
  --> src/lib.rs:97:45
   |
97 | #![cfg_attr(all(not(stable), test), feature(test))]