Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hyper Upgrade #1925

Open
2 of 26 tasks
jdisanti opened this issue Oct 31, 2022 · 3 comments
Open
2 of 26 tasks

Hyper Upgrade #1925

jdisanti opened this issue Oct 31, 2022 · 3 comments
Labels
client tracking Meta-issues to track overall progress

Comments

@jdisanti
Copy link
Collaborator

jdisanti commented Oct 31, 2022 •
edited by aajtodd
Loading

This tracks progress on the upgrade to Hyper 1.0

Many of these changes are prototyped in this branch which can send an E2E request with RusTLS

Implementation Tasks

Upstream Changes

  • Backport capture_connection and poison to hyper-util
  • Create crate for 0.14 -> 1.x bridge. This allows us to use hyper-rustls and hyper-nativetls against the RC (or 1.0)

SDK changes

  • Backwards compatible solution for SegmentedBuf in ByteStream
  • hyper::body::channel() replacement for dvr
  • Careful upgrade + testing of AwsChunkedBody—the Frame API changes the flow here a little bit
  • Update all tests
  • Update Checksum Body
  • Add Spawn to AwsSmithyAsync—bridge this with Hyper Executor (you now must provide an executor to create a Hyper builder)
  • Event Stream Upgrade

Testing Tasks

  • Simple request/response with:
    • Native TLS
    • Rustls
  • Streaming request/response with:
    • Native TLS
    • Rustls
  • Checksum validating response (S3 with checksums)
  • Checksum calculating request (S3 with checksums)
  • Unidirectional event stream operation (e.g., Transcribe Streaming and S3 Select):
    • HTTP/1.1
    • h2
    • Native TLS
    • Rustls
  • Bidirectional event stream operation (Pokemon client/server test?):
    • h2
    • Native TLS
    • Rustls
@jdisanti
Copy link
Collaborator Author

jdisanti commented Dec 7, 2022 •
edited by rcoh
Loading

I spent some time working on this this week. I was able to get aws-smithy-http compiling with most tests passing, and some of aws-smithy-checksums (ended up stubbing out the checksum calculating body to move forward). My work is available on the hyper-1x-experimentation-dec-7-2022 branch. Findings below.

Further work that is unblocked right now:

  • Fix failing tests in aws-smithy-http after upgrade
  • Reimplement checksum calculating body in aws-smithy-checksums to support new Body trait

Prerequisites before continuing:

  • Need hyper-util to release with a Connect/Connection traits and connection pool
  • Need an upgraded TLS library (hyper-tls or hyper-rustls) to actually test the SDK. We can do this work ourselves if the previous prerequisite is completed.

Work that can be done after prerequisites:

  • Upgrade or wait for hyper-rustls to support hyper 1.x
  • Upgrade or wait for hyper-tls to support hyper 1.x
  • Fix dvr in aws-smithy-client (transition from hyper::body::channel() to http_body_util::StreamBody)
  • Continue investigation

@jdisanti
Copy link
Collaborator Author

jdisanti commented Dec 8, 2022

Note: On the Body impls, it should be safe to assume trailers come after data frames since hyper will error out otherwise.

@jdisanti jdisanti self-assigned this Dec 9, 2022
@jdisanti
Copy link
Collaborator Author

jdisanti commented Dec 9, 2022 •
edited
Loading

Findings so far:

  • Depending on what hyper-util ends up supporting, we may need to fully implement the HTTP versioning RFC to avoid needing to worry about ALPN (or it may be cheaper to do so).

Work in progress test matrix:

  • Simple request/response with:
    • Native TLS
    • Rustls
  • Streaming request/response with:
    • Native TLS
    • Rustls
  • Checksum validating response (S3 with checksums)
  • Checksum calculating request (S3 with checksums)
  • Unidirectional event stream operation (e.g., Transcribe Streaming and S3 Select):
    • HTTP/1.1
    • h2
    • Native TLS
    • Rustls
  • Bidirectional event stream operation (Pokemon client/server test?):
    • h2
    • Native TLS
    • Rustls

@jdisanti jdisanti moved this to In Progress in AWS Rust SDK Public Roadmap Dec 9, 2022
@jdisanti jdisanti changed the title Start upgrade to hyper 1.0 RC1 Start upgrade to hyper 1.0 RC2 Jan 10, 2023
@rcoh rcoh changed the title Start upgrade to hyper 1.0 RC2 Hyper Upgrade Apr 13, 2023
@rcoh rcoh added the tracking Meta-issues to track overall progress label Apr 13, 2023
@rcoh rcoh assigned rcoh and unassigned jdisanti Apr 13, 2023
@jdisanti jdisanti mentioned this issue Nov 28, 2023
Open
11 tasks
@rcoh rcoh moved this to In Progress in AWS Rust SDK Public Roadmap Jan 17, 2024
This was referenced Mar 4, 2024
Open
Open
@rcoh rcoh mentioned this issue Mar 5, 2024
Merged
2 tasks
jdisanti pushed a commit that referenced this issue Mar 7, 2024
@rcoh
Add Initial Support for Hyper 1.0 (#3461)
f68b5ee 
## Motivation and Context
- #1925 

## Description
This adds a minimal Hyper client, focusing on not exposing any unstable
APIs. For this reason, the `Client::Builder` customization API is not
exposed anymore. We do this because at some point in the future, we will
likely move away from the hyper-util based Client.

The code for this was lifted directly from the Hyper 0.14 implementation
but updated for new traits.

However, this does come with some new valuable pieces:
1. Support for aws-lc (no FIPS yet)
2. Support for providing a custom DNS resolver

## Testing
- E2E test with Hyper. A Canary should also be added
(awslabs/aws-sdk-rust#1089)

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
@jdisanti jdisanti added the client label Apr 5, 2024
@rcoh rcoh removed their assignment Apr 25, 2024
@Velfi Velfi mentioned this issue May 30, 2024
Merged
2 tasks
github-merge-queue bot pushed a commit that referenced this issue Jun 3, 2024
@Velfi
implement http-body 1.0 for PathBody (#3673)
9c1ae5a 
## 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 -->
#1925 

## Description
<!--- Describe your changes in detail -->
Implements the v1 `http_body::Body` trait for `PathBody`. Part of the
ongoing hyper v1 upgrade.
This also moves a pre-1.0 impl into its own module.

## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
I ported the tests too

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
@aajtodd aajtodd mentioned this issue Aug 19, 2024
Merged
1 task
github-merge-queue bot pushed a commit that referenced this issue Aug 21, 2024
@aajtodd
backport connection poisoning to hyper 1.x client (#3795)
6a7dcbe 
## 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 -->
#1925

## Description
Backports connection poisoning that hyper 0.14 HTTP client has to the
hyper 1.x client.

See also:
* upstream support: hyperium/hyper-util#121

## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## 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.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
@aajtodd aajtodd mentioned this issue Sep 9, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Sep 11, 2024
@aajtodd
deprecate http-02x presign APIs (#3823)
db1a9f1 
## Motivation and Context
* #1925
* awslabs/aws-sdk-rust#977

## Description
Deprecate http-02x APIs from inlineable `PresignedRequest` API. These
should have been feature gated originally but they weren't. For now
we'll mark them deprecated and encourage people to move to the 1.x
equivalents.

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [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._
aws-sdk-rust-ci pushed a commit to awslabs/aws-sdk-rust that referenced this issue Sep 17, 2024
@aajtodd @aws-sdk-rust-ci
[smithy-rs] deprecate http-02x presign APIs (#3823)
af04392 
## Motivation and Context
* smithy-lang/smithy-rs#1925
* #977

## Description
Deprecate http-02x APIs from inlineable `PresignedRequest` API. These
should have been feature gated originally but they weren't. For now
we'll mark them deprecated and encourage people to move to the 1.x
equivalents.

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [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 aajtodd mentioned this issue Oct 7, 2024
Merged
aajtodd added a commit that referenced this issue Oct 14, 2024
@aajtodd
consolidate http client implementation(s) (#3866)
e616942 
## 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._
@xxchan xxchan mentioned this issue Oct 29, 2024
Closed
This was referenced Dec 4, 2024
Open
Merged
aajtodd added a commit that referenced this issue Dec 12, 2024
@aajtodd
enable hyper1 as default http client (#3939)
ba89a32 
## Motivation and Context
* #1925
* awslabs/aws-sdk-rust#977

## Description
* Add a new `default-http-connector` feature to `aws-smithy-runtime`
that enables hyper 1.x with rustls+aws-lc as the default HTTP client
plugin.
* If both the legacy `connector-hyper-014-x` feature is enabled the new
feature takes precedence such that the default HTTP client plugin favors
hyper 1 if both features are enabled.
* Update codegen to enable the new `default-http-connector` feature
instead of hyper 0.14
* NOTE: we can't break the existing `rustls` feature flag so it has
instead been updated to enable the `default-http-connector` feature.
* Importantly this still uses rustls as the TLS provider but the crypto
provider now defaults to aws-lc (which is coincidentally what rustls now
defaults to as well). This is likely to break _someone_ somewhere due to
build requirements changing (e.g. CMake now be required on certain
platforms or other build tools needed).
* Updated `aws-config` to default to hyper1 for the default credentials
chain.
* We have two features in `aws-config`, `rustls` and `client-hyper`,
that seem to be used entirely to enable the `aws-smithy-runtime`
features `tls-rustls` and `connector-hyper-0-14-x` features (both are
required for the default HTTP client plugin to work prior to this PR). I
think the _intent_ behind these features was "the user is not providing
an HTTP client explicitly so we need a default one to be available".
I've added a new feature to `aws-config` for this,
`default-http-connector` and updated the existing features to be
synonyms. We don't use `rustls` or `hyper 0.14.x` directly in
`aws-config` so I think this is a more clearly defined flag and conveys
it's intent better.
* Added a new `legacy-test-util` feature flag to `aws-smithy-runtime`.
The rationale for this is that the `test-util` feature provides testing
utilities for other things from `aws-smithy-runtime` but it also brings
in the (now) legacy hyper 0.14 HTTP testing facilities. I've left
`test-util` to mean what it does today and be backwards compatibile (for
now anyway) and in future we can ship a (breaking) change to disable the
legacy test utils by default (and by extension stop compiling the legacy
hyper ecosystem in all of our tests)
* Fixed an issue in `examples/pokemon-service-common` due to codegen no
longer generating clients with the `aws-smithy-runtime/tls-rustls`
feature enabled by default (they are using the
`HyperClientBuilder::build_https()` method directly but relying on
feature unification to enable the method)

## Questions

* Bikeshed any feature flag names. e.g.
`aws-config/default-http-connector` could be more generic like
`default-providers` or something. Today we use it to mean "we need a
default HTTP client" but you can imagine a future where we need other
default runtime components to exist and be configured. Perhaps that is
what we want from this flag?
 

----

_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
Assignees
No one assigned
Labels
client tracking Meta-issues to track overall progress
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jdisanti @rcoh