[HTTP 1.x] Add legacy crates to maintain [email protected] support during migration

[drganjoo]

This PR introduces two new legacy crates (aws-smithy-legacy-http and aws-smithy-legacy-http-server) that maintain support for [email protected]
while the codebase transitions to [email protected].

Background

As part of the HTTP 1.x migration effort (see branch feature/http-1.x), we're adding support for generating server SDKs that depend on [email protected] via a new http-1x codegen flag. However, we need to maintain backward compatibility with [email protected] for existing users.

Why Legacy Crates?

Initially, we attempted to pin dependencies to the last versions that supported [email protected]. However, this approach failed because:

• The codegen tests produce SDKs with path dependencies on crates
• These crates transitively depend on the same crates we were trying to pin
• This created version conflicts that couldn't be resolved with simple pinning

Solution

Creating dedicated legacy crates solves this problem by:

1. Isolating [email protected] dependencies - Clear separation between [email protected] and [email protected] codepaths
2. Easier maintenance - We can port changes back and forth between versions without checking out old commits
3. Simpler development workflow - Developers don't need to switch branches/commits to maintain [email protected] support
4. Clearer intent - Makes it explicit which code supports which HTTP version

Changes in this PR

• Added aws-smithy-legacy-http crate (forked from aws-smithy-http with [email protected] support)
• Added aws-smithy-legacy-http-server crate (forked from aws-smithy-http-server with [email protected] support)
• Updated rust-runtime/Cargo.toml to include both legacy crates in the workspace

Note

This PR is split out from the main [email protected] work to make it easier for reviewers to evaluate just the legacy crate additions separately from the codegen changes. By default, [email protected] remains the default - the http-1x flag must be explicitly enabled to use [email protected].

[rcoh]

can you target mainline with this instead?

[rcoh]

hmmm...I guess we still need these features? event streams currently use aws-smithy-http based types. I guess the client won't use the legacy crate right? We should have a test case that ensures generated clients never include clients.

[drganjoo]

The generated clients would never use these aws-smithy-legacy-* crates because the Kotlin class that adds these dependencies is defined in the HttpDependencies data class within the server module. There are no CargoDependencies defined for the legacy crates in the core module either. The client code has no reference to them unless someone explicitly adds them at a later stage.

I will add a test in the client to ensure they are not added.

[rcoh]

we don't need a lot of this stuff right? I guess I wonder if we should prune out the parts of aws-smithy-http-legacy we don't need. maybe its OK.

[drganjoo]

I would like to keep it as it originally existed to ensure we don't break compatibility for users who still want to generate [email protected] SDKs. Therefore, these two crates are an exact copy of their original state before we decided to remove [email protected] support from them.

[drganjoo]

can you target mainline with this instead?

It now targets main.

[github-actions]

A new generated diff is ready to view.

• No codegen difference in the AWS SDK
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.