AWS changes date format for S3 expires directive
It feels like there are a thousand services in Amazon Web Services (AWS), though I only use like a dozen of them. Most of the services I use just run by themselves, and it’s only two or three of them that I need to actively manage.
Probably the vast majority of AWS users use the Simple Storage Service (much better known as S3) for one purpose or another, as do I. All S3 does is store files, or objects.
In some use cases, it’s useful to attach expiration metadata to an S3 object, like for example, if it’s meant to be used by CloudFront.
A CloudFront edge location fetches an object from an S3 bucket, then caches it so it can serve the S3 object again and again without having to go back to the S3 bucket each time. And that’s good, because it’s faster.
But after a while, we might want the CloudFront edge location to fetch a fresh copy of an S3 object.
As a toy example, consider a department store running a Christmas in July sale for most of July. We want the website to use a Christmas in July theme, made up of assets like style sheets and images referenced from files with standard names like index.html and main.css.
But close to August, we want it to switch over to the Back to School theme. So, for example, we specify that index.html expires on July 28 of this year.
Then, if a customer loads the page on July 27, the CloudFront edge location serves up the cached page with the Christmas in July theme, but if that same customer loads the page on July 28, the CloudFront edge location retrieves a new copy of index.html, one that might have an expiration date just before Labor Day.
We used to do that by specifying a date in the YYYY-MM-DD format when we upload to S3. Such as 2024-07-28 in the toy example. Easy enough, right?
But AWS is always evolving, presumably for the better, though it’s not always clear what the rationale for a change is, even if you can see how the change might be useful to other AWS users.
S3 has become extremely finicky about the date format for the expiration metadata.
So now you have to put in that date in a very specific format, and specify a time. The example AWS gave me here is for some reason nine years in the past: “Wed, 21 Oct 2015 07:28:00 GMT”.
I had assumed in the past that the time with the previous format was simply midnight in the pertinent time zone, e.g., if you’re in U. S. East (N. Virginia), the expiration in July 28 would be at midnight in Eastern Daylight Time.
For my use case, I don’t really care at what time on the date I specify the expiration happens. But I can imagine why this would be important for other AWS users, that they would want to be able to specify the time and specify the time zone.
Even so, why is AWS making us specify the day of the week? And if you get it wrong, it refuses to upload anything. Couldn’t the S3 upload page provide us with a calendar and clock widget?
Still, I prefer this to having to be doing a whole bunch of CloudFront invalidations.