CopyObjectAsync fails on NetApp S3 due to x-amz-copy-source

[Maoo690]

Hi all,

I’m using the AWS SDK for .NET (AmazonS3Client.CopyObjectAsync) against a NetApp S3 backend (ONTAP 9.12+). The call consistently fails due to an issue with the x-amz-copy-source header formatting.
The SDK automatically URL-encodes the x-amz-copy-source header. For example:

x-amz-copy-source: test-bucket%2Ftest.txt

but NetApp S3 rejects the encoded format and throws:

Amazon.S3.AmazonS3Exception: The specified copy-source format is invalid.

Is there a way to configure the AWS .NET SDK to prevent encoding / as %2F in x-amz-copy-source?
Any insights or best practices would be much appreciated. Thanks!

[sankettangade]

Hi @Maoo690,

I've reproduced this issue and confirmed that CopyObjectAsync works correctly with AWS S3. The AWS SDK properly URL-encodes the x-amz-copy-source header (bucket%2Fkey), which is standard behavior and works as expected with AWS S3.

PUT /copied-file.txt HTTP/1.1

amz-sdk-request: attempt=1; max=3
x-amz-copy-source: s3-copy-test-c4ea3cefaffd429a9296d68897d64ae7%2Fsource-file.txt
X-Amz-Date: 20250902T211707Z

While the .NET SDK is designed to be compatible with third-party S3 services, full compatibility is not always guaranteed due to implementation differences in these services.

This appears to be a NetApp S3 compatibility issue - their implementation doesn't handle URL-encoded headers properly, unlike standard AWS S3.

Possible solutions:

1. Custom HTTP handler to decode the header before sending to NetApp S3
2. Use GetObject + PutObject instead of CopyObject
3. Contact NetApp to fix their S3 API compatibility

I can provide code samples for the custom handler approach if needed.

[Maoo690]

Hi @sankettangade ,

Thanks for sharing this suggestion! I tried implementing a custom HTTP handler myself, but it caused signature mismatches with AWS Signature.

If you happen to have a sample showing how to implement a custom handler without breaking the request signature, I would really appreciate it.

Thanks again!

[sankettangade]

This signature error is likely caused by the custom handler modifying the request headers after the SDK has already calculated the signature. The SDK uses request signing (SigV4) where the signature is calculated based on the exact request content, including headers.
The custom HTTP handler approach, has limitations due to AWS's request signing mechanism.

I would recommend:

1. Reach out toNetApp to fix their S3 API compatibility to properly handle URL-encoded headers like standard AWS S3.
2. Use GetObject + PutObject instead of CopyObject