- 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.