Consider HTTPClient to support RoundTripper

[ivankatliarchuk]

Describe the feature

Currently, AWS SDK configuration offers two HTTP client options: using the default BuildableClient or providing a custom http.Client. The latter, however, often lacks out-of-the-box support for key AWS features like AWS_CA_BUNDLE, that only works if HttpClient is of BuildableClient type, often forcing users to replicate complex SDK logic or use library specific midleware. Nothing wrong with the approach itself.

We propose direct http.RoundTripper support, similar to how Kubernetes (client-go) and OpenTelemetry (otelhttp) integrate it. This would enable a cleaner extensibility model, for example, via a NewBuildableClient().WrapperFunc(func(rt http.RoundTripper) {})... method.

The proposal is to support RoundTripper, examples

1. kubernetes https://github.com/kubernetes/client-go/blob/ec5b832e6085a572b8c325dafe9323ff18174732/rest/config.go#L107
2. opentelemetry https://github.com/open-telemetry/opentelemetry-go-contrib/blob/caee80916a50f168c7152967dabaefd0c3cd17c0/instrumentation/net/http/otelhttp/transport.go#L26

Use Case

In external-dns for example we instrumenting HTTP requests with project specific metrics, traces that do require capturing request/response statistics. AWS SDK library we could not instrument it with RoundTripper pattern, which is quite different to other providers, and sdk middleware instrumentation is required.

Other use cases

• BuildableClient use transport http.RoundTripper instead of transport *http.Transport #2405
• Request: Create a V4 Signing function that takes just a *http.Request #528

Proposed Solution

Re-use kubernetes or opentelemetry approach with RoundTripper

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

v1.36.6

Go version used

1.24

[lucix-aws]

I'm pretty sure my comment from #2405 (comment) still applies here?

[ivankatliarchuk]

Indeed. Has anything changed since then? Are there still no plans to revisit this design decision?

s there any consideration being given to introducing a common interface, or perhaps moving the logic from this line

aws-sdk-go-v2/config/resolve.go

Line 64 in f9f7a6b

client := trOpts.WithTransportOptions(func(tr *http.Transport) {

under NewBuildableClient?

Example interface as one of the options

type Interface interface {
  WithTransportOptions(func(tr *http.Transport)
}

or

type Interface interface {
  GetTransport() *http.Transport
}

[lucix-aws]

I don't really understand your suggestions there, that seems like what we have now.

I'm fine leaving this open though since I agree it would be an improvement. I just don't think there will be any way to do this without cutting over to something like a BuildableClient2 or something like that that removes the concrete typing.

[lucix-aws]

(which on its own would also have problems, because people are probably doing assertions on options.HTTPClient right now and expecting it to be BuildableClient)