consolidate http client implementation(s) #3866
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
Velfi
reviewed
Oct 10, 2024
Comment on lines
-7
to
-10
| default = "deny" | ||
| unlicensed = "deny" | ||
| copyleft = "deny" | ||
| allow-osi-fsf-free = "neither" |
There was a problem hiding this comment.
I updated cargo-deny in the docker image to try and fix the panic happening due to some edge case triggered by aws-smithy-http-client. These are all the default now and an error on latest version. See EmbarkStudios/cargo-deny#611
Velfi
approved these changes
Oct 10, 2024
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
2 tasks
aajtodd
added a commit
that referenced
this pull request
Oct 23, 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 -->
Previous PR(s):
* #3866
## Description
This PR migrates all of the HTTP related `test-util` feature to the new
`aws-smithy-http-client` crate.
* Re-export the relocated types from `aws-smithy-runtime`. I've tried to
ensure the feature gates line up correctly to what was there before. All
existing code depending on the `test-util` feature compiles and runs
still in `smithy-rs`.
* Updated the internals of all `test-util` code to be based on `hyper-1
/ http-1`.
* There were two functions `legacy_infallible::infallible_client_fn` and
`legacy_capture_request` that I had to just duplicate with the legacy
types to avoid a breaking change to them. These will be re-exported from
`aws-smithy-runtime` as the original types but otherwise not be used
going forward.
Next steps:
* Deprecate the old `test-util` APIs and update all of our usage of
`test-util` to be based on the new API's in `aws-smithy-http-client`. I
may ask for team to help in this effort as it should be relatively
straight forward migration work.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] For changes to the smithy-rs codegen or runtime crates, I have
created a changelog entry Markdown file in the `.changelog` directory,
specifying "client," "server," or both in the `applies_to` key.
- [x] For changes to the AWS SDK, generated SDK code, or SDK runtime
crates, I have created a changelog entry Markdown file in the
`.changelog` directory, specifying "aws-sdk-rust" in the `applies_to`
key.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
aajtodd
added a commit
that referenced
this pull request
Nov 20, 2024
…d new config (#3914) ## Motivation and Context Yet another follow up to: #3866 ## Description * Refactor the hyper 1 implementation into multiple modules to make it (slightly) easier to navigate (separating TLS, DNS, and timeout concerns into new/separate modules) * Refactors the hyper 1 implementation to allow for additional TLS provider implementations (e.g. s2n). Before we just exposed a `CryptoMode` but that is only applicable to rustls. I've swapped this for a new `TlsProvider` concept * Refactored how connectors are built. Before we were taking a TLS connector and wrapping it (via `Connector`). But this is structurally awkward since our `Connector` is analogous to hyper_utils' [`HttpConnector`](https://docs.rs/hyper-util/latest/hyper_util/client/legacy/connect/struct.HttpConnector.html#) (or supposed to be anyway). The updated structure forces our `Connector` to build the `HttpConnector` (which is the lowest layer/TCP connector) and then (if enabled) wrap it in TLS, and then finally wrap it with the SDK timeouts. ``` // build function returns a connector that looks like this as far as layering goes: Connector<TlsProviderSelected>.build() -> SdkTimeouts(TlsConnector(HttpConnector)) ``` * Exposed additional builder setting for `TCP_NODELAY` (and defaulted it to true). * Exposed additional builder setting for binding to a specific NIC * Fixed feature flags (powerset build was failing locally due to invalid or misconfigured feature flag application) * Renamed TLS feature flags to be associated with the underlying TLS lib (e.g. `crypto-aws-lc` -> `rustls-aws-lc`) **NOTE**: Apologies in advance, the diff didn't quite come out as I wanted. `client.rs` replaced `hyper_1.rs` (several modules of `hyper_1.rs` were split out into new modules). Everything in `timeout.rs` and `dns.rs` did not change. ---- _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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
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
hyper1rather thanmainhyper-0.14andhyper-1.xsupport into a newaws-smithy-http-clientcrate.hyper 0.14fromaws-smithy-runtime.aws-smithy-experimentalfor hyper 1.x and leave breadcrumb for where it lives now.CaptureSmithyConnectionintoaws-smithy-runtime-apiso that it can be used by new crate without creating a circular dependency.Why a new crate?
Several reasons:
Cargo.tomlis 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.aws-smithy-runtimemakes 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.aws-smithy-runtimeand generated SDKs to choose a default configuration but customers can pull in this newaws-smithy-http-clientcrate and enable different flags for specific use cases (e.g. FIPS).hyper-utillegacy client, this gives us a natural place for that should we go down that route)Future
Where are we going?
aws-smithy-runtime/src/client/http/test_utilinto theaws-smithy-http-clientcrate. 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 fromaws-smithy-runtimefor now.hyper-utilis not 1.x we can't expose theHyperClientBuilderlike 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.aws-lcthe default (at least onunix).s2n-tlstoaws-smithy-http-clientand reconcile related crypto/tls feature flags with this in mind.aws-smithy-runtimeand generated clients to be hyper 1.x and add appropriate new flags, etc.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.