[tracking] support hyper/http/etc. 1.0

[mattklein123]

This is the tracking issue for support for Http & Hyper 1.0

Describe the feature

There may already be a tracking issue on this (I couldn't find it), but was hoping to understand the timeline of supporting the entire hyper 1.0 cascade throughout the ecosystem. For examples functions like: https://docs.rs/aws-smithy-types/latest/aws_smithy_types/body/struct.SdkBody.html#method.from_body_0_4 are sprinkled around and would need to hopefully support 1.0 variants.

Checklist

• Support http = 1.0 in the HttpRequest shim smithy-lang/smithy-rs#3365
• Construct SdkBody from http-body = 1.0 bodies (Add support for constructing sdk body types from http-body 1.0 smithy-lang/smithy-rs#3300)
• Construct SdkBody from http-body = 1.0 bodies that are !Sync via an internal mutex
• SdkBody implements http-body = 1.0 via a shim #1046
• SdkBody natively implements http-body 1.0 with 0.4x behavior implemented as a shim.
• Internal code works based on http-body 1.0 frames instead of http-body 0.4.x
• hyper_ext_1_0 added utilizing Hyper 1.0
• Default clients use Hyper 1.0 (behavior major version)
• Update QueryWriter to either operate on http = 1 or HttpRequest shim smithy-lang/smithy-rs#3367
• Add Hyper 1.0 test to the Canary #1089
• Compute CacheKey based on RuntimeComponents to support late-overrides #1090

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[jdisanti]

It's definitely on our radar, and we played around with the release candidates before 1.0 was cut. Previous work was tracked in smithy-lang/smithy-rs#1925, but this issue is better for visibility.

[jdisanti]

This is blocking use of the SDK with Axum 0.7 for streaming uploads to S3.

Mentioned in #989

[mattklein123]

This is blocking use of the SDK with Axum 0.7 for streaming uploads to S3.

This is actually my exact use case. :)

[jdisanti]

It looks like you can use the tower-hyper-body-compat crate to convert Axum's http 1.x body into the http 0.4 body that the SDK needs as a workaround. Although, that crate needs to be updated to the full 1.x version instead of the release candidates.

[mattklein123]

It looks like you can use the tower-hyper-body-compat crate to convert Axum's http 1.x body into the http 0.4 body that the SDK needs as a workaround. Although, that crate needs to be updated to the full 1.x version instead of the release candidates.

OK thanks will keep an eye on that. At this point given how disruptive this change is (why?), I'm waiting for things to settle a bit. :)

[rcoh]

We'll have a fix for the specific task of creating a body from an Http 1x body out soon: smithy-lang/smithy-rs#3300

[rcoh]

this is now available: https://docs.rs/aws-smithy-types/latest/aws_smithy_types/body/struct.SdkBody.html#method.from_body_1_x

[mattklein123]

this is now available: https://docs.rs/aws-smithy-types/latest/aws_smithy_types/body/struct.SdkBody.html#method.from_body_1_x

@rcoh I've been picking away at the upgrade in a branch and tried to use this. Unless I'm missing something this doesn't work for the axum use case. For reasons I'm not sure about the axum body is not Sync (it's UnsyncBoxBody). The bounds on this method require a Sync body. Can the bounds be relaxed here to remove Sync?

[rcoh]

The bounds on this method require a Sync body. Can the bounds be relaxed here to remove Sync?

Hmm, possibly. I believe we could create an internal variant that wrapped the body in a tokio::sync::Mutex which would make it sync again. SdkBody is Sync currently so we can't take that bound away without causing breaking changes.

Since the mutex would be uncontended, I don't expect it to have any performance implications.

I've added another checklist item at the top.