Contrib.social

Backblaze B2 - Unsupported header 'x-amz-checksum-crc32'

Open on Drupal.org →
Created on 17 March 2025, about 1 month ago

Problem/Motivation

Hello.
I'm using Drupal 11.1 with PHP 8.3.17.
I installed s3fs 8.x-3.7 using Composer.
Every time I try to validate my configuration I get errors about "Unsupported header 'x-amz-checksum-crc32'".

My configuration to Backblaze B2 is as follows:

- Custom Credentials File Location: /home/me/s3fs_credentials.ini
- S3 Bucket Name: my_bucket
- Enable CNAME
- CDN Domain Name: my_bucket.s3.us-west-004.backblazeb2.com
- Map Domain Name to specific path: entire bucket
- Use a custom host
- Custom hostname: s3.us-west-004.backblazeb2.com
- Always serve files from S3 via HTTPS


These errors appear when I try to validate my configuration:

Unable to validate your s3fs configuration settings. Please configure S3 File System from the admin/config/media/s3fs page or settings.php and try again.
An unexpected error occurred. Error executing "PutObject" on "https://my_bucket.s3.us-west-004.backblazeb2.com/s3fs-tests-results/writ..."; AWS HTTP error: Client error: `PUT https://my_bucket.s3.us-west-004.backblazeb2.com/s3fs-tests-results/writ...` resulted in a `400 Bad Request` response: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> InvalidArgument Unsupporte (truncated...) InvalidArgument (client): Unsupported header 'x-amz-checksum-crc32' received for this API call. - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> InvalidArgument Unsupported header 'x-amz-checksum-crc32' received for this API call.
Could not upload file as publicly accessible. If the bucket security policy is set to BlockPublicAcl ensure that upload_as_private is enabled in your settings.php $settings['s3fs.upload_as_private'] = TRUE;
Error message: Error executing "PutObject" on "https://my_bucket.s3.us-west-004.backblazeb2.com/s3fs-tests-results/publ..."; AWS HTTP error: Client error: `PUT https://my_bucket.s3.us-west-004.backblazeb2.com/s3fs-tests-results/publ...` resulted in a `400 Bad Request` response: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> InvalidArgument Unsupporte (truncated...) InvalidArgument (client): Unsupported header 'x-amz-checksum-crc32' received for this API call. - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> InvalidArgument Unsupported header 'x-amz-checksum-crc32' received for this API call.

🐛 Bug report
Status

Active

Version

3.7

Component

Code

Created by

🇧🇷Brazil lrrosa

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @lrrosa
  • Comment about 1 month ago →
    🇺🇸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-api

    This 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?

  • Comment about 1 month ago →
    🇧🇷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

  • Comment about 1 month ago →
    🇺🇸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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024