put_object_retention returns "Missing required header for this request: Content-Md5. (Aws::S3::Errors::MissingContentMD5)"

[dup2]

Describe the bug

When trying to prolong a retain_until_date of a specific object version using put_object_retention, I get an error about a missing header Content-MD5. However the SDK doc states that this header should be calculated automatically.

Here is a sample of the code:

client.put_object_retention(
      bucket: bucket,
      key: key,
      version_id: version,
      retention: {
        mode: "GOVERNANCE",
        retain_until_date: expires_at.iso8601
      }
    )

This code produces the error Missing required header for this request: Content-Md5. (Aws::S3::Errors::MissingContentMD5)

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

I expect this to set the new retain_until_date.

Current Behavior

The error Missing required header for this request: Content-Md5. (Aws::S3::Errors::MissingContentMD5)

Reproduction Steps

client.put_object_retention(
      bucket: bucket,
      key: key,
      version_id: version,
      retention: {
        mode: "GOVERNANCE",
        retain_until_date: expires_at.iso8601
      }
    )

Possible Solution

No response

Additional Information/Context

No response

Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version

aws-sdk-s3 (1.178.0)

Environment details (Version of Ruby, OS environment)

3.2.6, Linux

[mullermp]

Thanks for opening an issue. I am investigating. What version of aws-sdk-core are you using?

[dup2]

Thanks for opening an issue. I am investigating. What version of aws-sdk-core are you using?

Thanks, here is the excerpt from our Gemfile.lock:

  aws-sdk-core (3.216.0)
      aws-eventstream (~> 1, >= 1.3.0)
      aws-partitions (~> 1, >= 1.992.0)
      aws-sigv4 (~> 1.9)
      jmespath (~> 1, >= 1.6.1)
    aws-sdk-kms (1.97.0)
      aws-sdk-core (~> 3, >= 3.216.0)
      aws-sigv4 (~> 1.5)
    aws-sdk-s3 (1.178.0)
      aws-sdk-core (~> 3, >= 3.216.0)
      aws-sdk-kms (~> 1)
      aws-sigv4 (~> 1.5)
    aws-sigv4 (1.11.0)
      aws-eventstream (~> 1, >= 1.0.2)

[mullermp]

I'm not able to reproduce this using the latest core and s3. After creating a bucket with object versioning and locking, I make a request just fine. Can you try updating all of your S3 gems?

[mullermp]

Are you using a third party provider by chance?

[dup2]

We will test this with the newest version of the SDK. In our tests we are using minio and in production also NetApp but this seems to be a client issue as there is not even a request sent.

[mullermp]

Ah, so you are using 3rd party clients. See this issue here: #3166. The third party provider will need to accept other checksums and not just md5, such as crc32, which the client will send by default. You have two options - pin your sdk to the version before, or you can drop in a plugin like in this issue: #3167

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[dup2]

Thanks for the hints and link, appreciated.

While we understand the integrity protection goal for data up- and downloads, other API interactions which do not transport object content (and are not mentioned in https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html) do not seem to benefit from this and thus the effect is even more confusing.

However it seems that this change is very surprising and has a bad smell on it (compatibility issues with other S3 API providers) - it was not even marked as breaking change..

[mullermp]

In this particular case, it was the removal of md5 less so than the data integrity check (we are supplementing crc32 here by default because that is how s3 modeled their changes). I understand your sentiment. The AWS SDKs are intended to be used with AWS products. 3rd party providers were called out as a risk but S3 continued with their decision.