InitiateMultipartUploadRequest throws a runtime exception when using non-standard storage classes

[pepijnve]

Describe the bug

AbstractPutObjectRequest stores the desired storage class as a plain String. It allows any value to be set in the request header.

InitiateMultipartUploadRequest on the other hand attempts to convert the given String to a StorageClass enumeration constant. When using non-standard values this causes an IllegalArgumentException to be thrown.

Expected Behavior

Multipart uploads can use non-standard storage class values the same way regular put object requests can.

Current Behavior

An IllegalArgumentException is thrown from StorageClass#fromString.

Reproduction Steps

new InitiateMultipartUploadRequest("bucket", "key").withStorageClass("ice_cold_storage")

Possible Solution

No response

Additional Information/Context

No response

AWS Java SDK version used

1.12.296

JDK version used

17.0.4.1

Operating System and version

macOS 12.5.1

[debora-ito]

Even though AbstractPutObjectRequest takes a plain String input, in the end the S3 CreateMultipartUpload API only accepts a well-defined list of values for storage class- https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html#API_CreateMultipartUpload_ResponseSyntax

so the restriction to use the enum values makes sense. Can you elaborate on your use case? Why do you want to provide a storage class that is not in the list?

[pepijnve]

Vendors other than Amazon use different storage class strings. I realise that's probably not a very relevant argument from an Amazon, but it would save me from having to fork the SDK for use in our product.

[debora-ito]

Yes, vendors other than Amazon are out of scope of the AWS SDKs, unfortunately. Marking this to auto close soon, let us know if you have any more questions.

[debora-ito]

I forgot to mention that Java SDK v2 CreateMultipartUpload takes a String setter for storage class - https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/s3/S3Client.html

so you can migrate to v2 if you're able to.

[pepijnve]

So be it. Not sure I understand the motivation given the availability of a PR, the non-breaking and trivial nature of the change, and the fact that other requests and the v2 sdk support this already, but ok.

[debora-ito]

We are sorry for the frustration. The team is working to bring SDK v2 up to feature parity, and having something that is already supported in v2 helps in our goal to migrate people from v1. That's one of the motivations.

[github-actions[bot]]

COMMENT VISIBILITY WARNING

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. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[pepijnve]

No worries, I bit the bullet and switched over to v2 in the meantime.