hyper-reverse-proxy
hyper-reverse-proxy copied to clipboard
A simple reverse proxy for use with Hyper and Tokio
hyper::header::from_static is a **const fn**, we can define our headers in const and remove lazy-static dep(move it to dev-dependency)
* [ ] rewrite docs main page with new examples * [ ] static client * [ ] ws support * [ ] notes on security * [ ] sync...
``` 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
The `host` header that is set by the proxy does not include the port. The easiest fix is to just remove the `host` header as it will be automatically set...
The [x-forwarded-host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host) header names the original host (including the port).
hyper_reverse_proxy::call every time need create and destroy connection to the reserse address, if add a new feature "keepalive a conntion pool" may improve performance awaresome.
We should allow folks to log failed requests in their preferred way, be it `printf`, `slog`, or something else...
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...
Go's [`httputil.ReverseProxy`] uses the defacto standard of the [`X-Forwarded-For`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) header, but I'm wondering if it would be better to use the standardised [`Forwarded`](https://tools.ietf.org/html/rfc7239) header instead. Unfortunately it is not implemented...