Customize S3's "Expires" field to handle invalid timestamps

[lucix-aws]

Some S3 shapes such as GetObject response and PutObject request have a header parameter Expires. It has been modeled as a String in the source coral model since 2014, but it is converted to timestamp shape without a timestamp format.

Today, serialization and deserialization implementation for this header is inconsistent across SDKs, CLIs and AWS console. Some tools such as CLI and console supports multiple timestamp formats while others are less lenient and only use the resolved timestamp format for serialization and deserialization. As a result, S3 objects uploaded using one SDK or tool may not be able to be downloaded with a different one. For example, assume there is an S3 object uploaded using AWS CLI with an invalid expires value aws s3 cp test.txt s3://mybucket/test.txt --expires 2023-11-01. If customers attempt to use the Go v2 SDK to download the same object, the request would fail due to parsing errors.

To address this issue in a backwards-compatible way in all affected SDKs (including this one), we are going to do the following:

1. customize deserialization of the Expires field to not fail the request on a failure to parse the response value
2. add a value, ExpiresString, to all responses with the Expires member, that will hold the unparsed value from the response

We will add a deprecation warning to the existing Expires field that cites this information, directing users to instead use ExpiresString.

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