Fix AWSCRTHTTPClient request bodies for HTTP/1.1 connections

[arandito]

Description

Previously, our AWSCRTHTTPClient attached request bodies via the CRT's request_body_generator parameter, which is only supported for HTTP/2 connections (source). This caused generated clients that only support HTTP/1.1 to throw the following error when making body-bearing requests:

smithy_core.exceptions.SmithyError: 2056 (AWS_ERROR_HTTP_MISSING_BODY_STREAM): Given the provided headers (ex: Content-Length), a body is expected.

This PR adds logic that routes HTTP/1.1 connections to attach bodies through the body_stream parameter on the request itself and keeps the generator path for HTTP/2.

Testing

• Generated H1-only service (STS) and confirmed calls no longer raise AWS_ERROR_HTTP_MISSING_BODY_STREAM
• Confirmed existing client integration tests succeed with changes

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Alan4506]

LTGM overall. Just wondering if there is a roadmap / tracking issue on the aws-crt-python side about when they will support HTTP/1.1 streaming request bodies, so we can switch this back from buffering.

[Alan4506]

Nit: do we want to use "is" instead of "==" to align with if force_http_2 and connection.version is not crt_http.HttpVersion.Http2:

smithy-python/packages/smithy-http/src/smithy_http/aio/crt.py

Line 271 in 720c0cb

if force_http_2 and connection.version is not crt_http.HttpVersion.Http2:

[arandito]

Good catch, yea enums should be compared based on identity so I can switch that. I will update this one I get additional feedback in case there are larger changes.

[arandito]

Fixed in 97aef6e

[arandito]

LTGM overall. Just wondering if there is a roadmap / tracking issue on the aws-crt-python side about when they will support HTTP/1.1 streaming request bodies, so we can switch this back from buffering.

Not yet. I am going to ask their team if this is on their roadmap as a follow-up. I'm not sure if there are protocol-level limitations on their side for why they can't support body generators for H1. This solution is an immediate fix to unblock future H1-only clients but ideally we can revert back to their generators if they add support in the future.