Sign Content-Type header on SigV4 requests

[thannaske]

We're running a S3-compatible storage solution built on Ceph RGW. With its most recent update to 19.2.6, Ceph fixed a security vulnerability (CVE-2026-54330) related to how the signature is calculated/treated. After the upgrade to 19.2.6 I stumbled across an issue with AsyncAws in terms of signature generation.

The issue first surfaced when I made a ListObjectsV2 request. AsyncAws sends Content-Type: application/xml on ListObjectsV2 requests but excludes it from SignedHeaders.

With the upgrade to 19.2.6, Ceph RGW it rejects this combination with 403 AccessDenied under its default SigV4 validation. This PR signs an existing Content-Type header on ordinary requests while retaining its exclusion from presigned URLs which is aligned with the signature behaviour in recent AWS SDKs.

Reproduction

The failure was reproduced with async-aws/core 1.29.2 and async-aws/s3 3.3.0, using both path-style and virtual-host addressing. The same credentials, region, operation and query parameters were used throughout:

Request variant	Result in both addressing modes
AsyncAws signature, original Content-Type, libcurl transport	403
AsyncAws signature, original Content-Type, Symfony transport	403
Same AsyncAws signature, removing only Content-Type	200
AWS PHP SDK 3.395.6 signer, Content-Type included in SignedHeaders	200
libcurl SigV4 signer, Content-Type included in SignedHeaders	200
libcurl SigV4 signer, no Content-Type	200

Rationale

The Ceph 19.2.6 verifier explicitly rejects a present Content-Type absent from the canonical headers. This is in conjunction with AWS' signing policy where it reads:

If the Content-Type header is present in the request, you must add it to the CanonicalHeaders list.

AWS PHP SDK recently made the same distinction proposed here: aws/aws-sdk-php#3310, merged June 19, 2026, removed Content-Type from ordinary signing exclusions while retaining its exclusion when presigning. That change addressed #3283.