- Issue created by @lrrosa
- πΊπΈUnited States cmlara
Sounds like this may be a new default in recent SDK versions
https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/s3-checksums....
Version 3.337.0 is January 15th. Rolling back should work as an initial fix.
This sounds like BackBlaze being non-compliant with the Full S3 protocol that they admit to:
https://www.backblaze.com/docs/cloud-storage-s3-compatible-apiThis isnβt a new feature, it has been around since at least the 2.x SDK, just added as a default enabled now. I would not want to try and disable this feature for all systems, and would like to avoid adding a configuration option for something that seems reasonable to expect to be standard.
I wonder if this can be disabled via a few of our hooks and this can go into documentation?
- π§π·Brazil lrrosa
Thanks for your answer. You're totally right. I'll rollback the SDK for now.
In their documentation there is a list of unsupported headers:
Requests that include the following checksum HTTP headers are rejected with a 400 Bad Request response:
x-amz-checksum-crc32
x-amz-checksum-crc32c
x-amz-checksum-crc64nvme
x-amz-checksum-sha1
x-amz-checksum-sha256
x-amz-checksum-algorithm
x-amz-checksum-mode - πΊπΈUnited States cmlara
The other options beyond rolling back the API is setting the environment variables or placing the configuration parameters in the shared config file (not the credentials config file).
I have read that CloudFront R2 is also impacted
Minio and Ceph appear to have support for this header (as does LocalStack that we use for the GItLab pipelines) which means the impacted hosts should be limited in general.
- πΊπΈUnited States metadaddy
Hi - Backblaze B2 added support for these checksum headers in July 2025 - the current AWS SDKs should work now.
- πΊπΈUnited States cmlara
Given above regarding B2 I'm going to close this as outdated.
I had previously noted R2 had issues (and their documentation still seems to imply no checksum support) however it appears they resolved this even before I made my previous post, ref, https://community.cloudflare.com/t/aws-s3-sdk-compatibility-inconsistenc...
We can certainly raise questions about the ethics of Amazon making a change like this in minor release, however it is unfortunately a complex discussion given the specifications for these headers were known well in advance of them being deployed and this can also be seen as a fault of the vendors for advertising S3 compatibility when they only offer partial support.
If anyone does encounter this, setting environment variables via settings.php is sufficient to prevent these errors.