-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Over in jsonrpsee which depends on hyper, the jsonrpsee maintainers observed that hyper-proxy is lacking in continuing updates/maintainership.
This is probably of most concern related to keeping the dependencies up-to-date within the Cargo.toml of hyper-proxy, assuming the crate is feature-complete and doesn't have any known bugs that are the responsibility of hyper-proxy to fix. But still, the jsonrpsee maintainers would prefer not to depend on a crate that is going stale, and doubly so when it pulls in security-related crates like rustls.
My question is, do the maintainers of hyper (this crate) consider the hyper-proxy crate to be the best crate for adding proxy middleware to a hyper HTTP client? Or are you planning on subsuming this functionality into the hyper crate itself? Or is there another crate that you would recommend that has a better maintainership record than hyper-proxy?
The jsonrpsee maintainers alluded to possibly writing this functionality themselves within the jsonrpsee crate if there's no better way, but that seems like a layering violation (a library that implements a proto on top of HTTP(S) as well as other transports shouldn't have to reinvent how to work with HTTP proxies).
My preference would be for the hyper maintainers to identify a supported way to add an HTTP proxy to a client. Then I can revise my pull request to jsonrpsee to use that recommended approach.