Update hyper #3710
Comments
|
Hi, we are currently working on a plan to make hyper 1.0 our default http client and deprecate the 0.14 client. Since this could be a breaking (or just unexpected) change for customers and we are 1.0 with strong backwards compatibility guarantees we are moving slowly and deliberately towards this goal to make sure it is minimally disruptive. Don't have any exact timelines to share, but it is something we are actively looking at right now. |
|
Thanks @landonxjames -- I'm a bit curious what disruptions you anticipate? I'm already seeing multiple versions of hyper in my graph (1.x from other dependencies, and now 0.14 from aws-config), and it's not obviously causing any problems, aside from undesirably bloating my cargo.lock, which is a fairly minor issue. It seems like the two versions can coexist fine? Anyway I appreciate your diligence to this issue, so I'm not criticizing exactly, just curious what specifically is the concern. |
This was referenced Aug 21, 2024
aajtodd
added a commit
that referenced
this issue
Oct 14, 2024
## Motivation and Context <!--- Why is this change required? What problem does it solve? --> <!--- If it fixes an open issue, please link to the issue here --> * #3710 * #1925 * awslabs/aws-sdk-rust#977 ## Description This is the first of what I'm going to assume will be several PRs on the path to migrating us to hyper 1.x. The goal is to reach a desired state as far as crate organization, feature flags, and how this is all enabled by default (eventually). This first PR just moves existing HTTP client support around as prep work for what's to come. NOTE: This is all getting merged into a staging branch `hyper1` rather than `main` * Migrate `hyper-0.14` and `hyper-1.x` support into a new `aws-smithy-http-client` crate. * re-export `hyper 0.14` from `aws-smithy-runtime`. * Remove support from `aws-smithy-experimental` for hyper 1.x and leave breadcrumb for where it lives now. * Migrate `CaptureSmithyConnection` into `aws-smithy-runtime-api` so that it can be used by new crate without creating a circular dependency. Why a new crate? Several reasons: * The entire hyper and rustls ecosystem bifurcates on hyper 0.x. The resulting `Cargo.toml` is kind of a mess as a result. In a new crate we can isolate this ugliness as well as manage feature flags more meaningfully with this in mind. * Placing the HTTP client implementation in `aws-smithy-runtime` makes it a load bearing crate for all of the HTTP and TLS related feature flags we may wish to expose _in addition to it's own feature flags_. This sort of explodes with the aforementioned bifurcation. * I expect `aws-smithy-runtime` and generated SDKs to choose a default configuration but customers can pull in this new `aws-smithy-http-client` crate and enable different flags for specific use cases (e.g. FIPS). * A new crate may be a good place to explore new functionality (e.g. we've considered forking our own implementation of `hyper-util` legacy client, this gives us a natural place for that should we go down that route) ## Future Where are we going? * I want to relocate all of `aws-smithy-runtime/src/client/http/test_util` into the `aws-smithy-http-client` crate. These are utilities for testing with a mock/fake HTTP client and they make more sense in this new crate. This also allows us to update the utils to support the hyper/http 1.x ecosystem and feature gate the legacy ecosystem. We can re-export the legacy ecosystem test support from `aws-smithy-runtime` for now. * Update our internal usage of these test utils with the new 1.x ecosystem and deprecate the old APIs but leave them in place. * I expect we'll deprecate them with a plan to remove or at least feature gate differently in the future with a recommendation to upgrade. * I want to explore the tickets/use cases people have asked for to see what/if we can do anything better with the hyper 1.x API surface. In particular I think we may want to just expose our own builder type (new type around hyper-util builder). * Because `hyper-util` is not 1.x we can't expose the `HyperClientBuilder` like we did previously. I don't think we should even if it was 1.x though, we should offer a "default client" with knobs for all the things we do want to support directly. Anything not found there you have to bring your own client configured to your heart's content. * We need to explore if we can make `aws-lc` the default (at least on `unix`). * I want to add optional support for `s2n-tls` to `aws-smithy-http-client` and reconcile related crypto/tls feature flags with this in mind. * Need to figure out how we set the default for `aws-smithy-runtime` and generated clients to be hyper 1.x and add appropriate new flags, etc. * Update changelogs, versions, lockfiles, etc. ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello, I'm going through my Cargo.lock, and I'm noticed that aws-config (and associated libraries) are pinned to an old version of hyper (^0.14.26) which may be related to being pinned to an old version of hyper-rustls (^0.24). I'm not super clear on how the versions are chosen here, since the code is all generated, and I can't find the relevant Cargo.toml / Cargo.lock files for these projects.
The current version of hyper is 1.3.1 and the current version of hyper-rustls is 0.27.2, both of which are being pulled into my project regardless by other dependencies. If you were able to update these dependencies it would shrink my Cargo.lock, and possibly my binary size, dramatically. I would appreciate it if this could be given a bit of attention.
The text was updated successfully, but these errors were encountered: