feat(s3): add expectContinueEnabled to S3Configuration

[joviegas]

Motivation and Context

Reported in #6459 (comment) by the Apache Hadoop S3A team — they configure ApacheHttpClient.builder().expectContinueEnabled(false) to disable Expect: 100-continue for their use case, but the SDK's StreamingRequestInterceptor re-adds the header anyway, making their setting ineffective. They requested a way to turn it off from the SDK side for rare emergencies where the header causes issues with proxies or S3-compatible stores.

We considered adding this control at the SdkHttpClient level, but since this behavior is specific to S3 (only S3's StreamingRequestInterceptor adds the header), exposing it on SdkHttpClient.Builder would mean adding public API surface across all HTTP clients and piping values from the HTTP layer up to S3 — when only Apache even has its own independent expectContinueEnabled setting. Putting it on S3Configuration keeps the control scoped to where the behavior lives.

Modifications

• Added expectContinueEnabled(Boolean) to S3Configuration (defaults to true, preserving existing behavior).
• Updated StreamingRequestInterceptor to read the config from SdkExecutionAttribute.SERVICE_CONFIG and skip adding the Expect: 100-continue header when expectContinueEnabled is set to false.
• Documented the Apache HTTP client nuance in javadoc — Apache independently adds Expect: 100-continue via its own expectContinueEnabled setting (which defaults to true), so setting expectContinueEnabled(false) on S3Configuration alone won't suppress the header on the wire when using Apache.

Example — fully disabling Expect: 100-continue with Apache:

S3Client s3 = S3Client.builder()
    .httpClientBuilder(ApacheHttpClient.builder().expectContinueEnabled(false))
    .serviceConfiguration(S3Configuration.builder()
        .expectContinueEnabled(false)
        .build())
    .build();

For all other HTTP clients (URL Connection, Netty, CRT), setting expectContinueEnabled(false) on S3Configuration is sufficient.

Testing

• Unit tests (StreamingRequestInterceptorTest): Parameterized tests covering expectContinueEnabled with true, false, null, no service config, non-streaming requests (GetObject), zero and non-zero content-length — 8 scenarios via @MethodSource. Also covers RFC 9110 compliance (zero vs non-zero content length for PutObject/UploadPart).
• Functional tests (Expect100ContinueHeaderTest): WireMock-based end-to-end tests across 5 HTTP client types (Apache, Apache with expectContinueEnabled=false, Apache with expectContinueEnabled=true, URL Connection, CRT sync, CRT async, Netty) × 14 config combinations × 2 operations (PutObject + UploadPart). Verifies the actual Expect header presence/absence on the wire.
• Manually verified CRT wire behavior using Log.LogLevel.Trace — confirmed the generic AwsCrtHttpClient passes the Expect header through (does not strip it).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

License

• I confirm that this pull request can be released under the Apache 2 license

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.