fix: add gcs compatibility flag to fix s3proxy GCS SigV4 signature mismatch

The AWS SDK v2 includes Accept-Encoding in SigV4 signed headers
which causes GCS to return a SignatureDoesNotMatch error because
GCS rewrites that header internally before verifying the signature.

Add a --gcs-compatibility / VGW_S3_GCS_COMPATIBILITY option for the s3proxy
backend that injects two Smithy finalize-layer middlewares: one removes
Accept-Encoding from the request immediately before the Signing step, and
a second restores it after signing so the header is still sent on the wire.

see: https://github.com/aws/aws-sdk-go-v2/issues/1816

This can be removed once GCS fixes this incompatibility.
This commit is contained in:
Ben McClelland
2026-04-14 10:53:26 -07:00
parent 393477aafd
commit 9816c2fdb3
4 changed files with 86 additions and 2 deletions

View File

@@ -628,6 +628,14 @@ ROOT_SECRET_ACCESS_KEY=
# VGW_S3_DEBUG will enable debug logging for S3 requests.
#VGW_S3_DEBUG=false
# VGW_S3_GCS_COMPATIBILITY enables Google Cloud Storage (GCS) S3 compatibility
# mode. When enabled, the Accept-Encoding header is excluded from the SigV4
# signed headers and restored after signing. This works around a signature
# mismatch caused by the AWS SDK v2 including Accept-Encoding in signed headers,
# which GCS does not support. See https://github.com/aws/aws-sdk-go-v2/issues/1816
# for details.
#VGW_S3_GCS_COMPATIBILITY=false
########
# azure #
########