Skip to content

Best Practice for HTTP Proxy Support? #3124

@allquixotic

Description

@allquixotic

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-featureCategory: feature. This is adding a new feature.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions