Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
lucix-aws opened this issue May 22, 2024 · 1 comment · Fixed by #2653
Closed

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

lucix-aws opened this issue May 22, 2024 · 1 comment · Fixed by #2653
Assignees
Labels
bug This issue is a bug. p1 This is a high priority issue queued This issues is on the AWS team's backlog

Comments

@lucix-aws
Copy link
Contributor

lucix-aws commented May 22, 2024

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.

@lucix-aws lucix-aws added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. p1 This is a high priority issue queued This issues is on the AWS team's backlog and removed needs-triage This issue or PR still needs to be triaged. labels May 22, 2024
@lucix-aws lucix-aws self-assigned this May 22, 2024
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. p1 This is a high priority issue queued This issues is on the AWS team's backlog
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant