[Bug]: S3 PutObject is missing a Content-MD5 header when writing to a bucket with a default object lock configuration

[caspereijkens]

Terraform Core Version

1.10.5

AWS Provider Version

5.85.0

Affected Resource(s)

We use the terraform AWS provider to provision infrastructure on a non-AWS S3 service. Since 5.85.0 we get the error in the title when trying to configure aws_s3_bucket_object_lock_configuration. I rolled back to 5.84.0 and there everything works again.

Expected Behavior

Configure aws_s3_bucket_object_lock_configuration on non-AWS bucket.

Actual Behavior

S3 PutObject is missing a Content-MD5 header when writing to a bucket with a default object lock configuration

Relevant Error/Panic Output Snippet

Terraform Configuration Files

resource "aws_s3_bucket_object_lock_configuration" "map" {
  for_each = {
    for key, value in var.bucket_configs : key => value
    if value.object_lock_enabled
  }
  bucket = each.value.bucket_name
  rule {
    default_retention {
      mode = "COMPLIANCE" 
      days = each.value.object_lock_days
    }
  }
}

Steps to Reproduce

Try to create a bucket and configure object locking on a non-AWS provider.

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[justinretzolk]

Hey @caspereijkens 👋 Thank you for taking the time to raise this! While we try not to break functionality with AWS-compatible services, it's not something we currently have the capacity to test against. No further action is needed from you at this point, I just wanted to let you know that it may take longer than normal for this to be looked into by the provider team. If a community member happens to pick this up and try to address it, we'd be happy to review.