I have a ton of files in Amazon S3 (served via Cloudfront) for which I have added an Expires header of Mon, Jan 1 2024 11:11:11 GMT

However, I have recently learned that setting an Expires header more than one year in the future violates the HTTP 1.1 RFC.

So is there a way in S3 to set a dynamic Expires that is always one year from the request date?

1 Answer 1


So is there a way in S3 to set a dynamic Expires that is always one year from the request date?

Not that I know of, and I doubt that dedicated support for this will be considered by the AWS team:

You are probably aware that one can't set a dynamic Expires: ... value as such because The only value valid in an Expires header is a HTTP date; anything else will most likely be interpreted as ‘in the past’, so that the representation is uncacheable. (see e.g. Controlling Freshness with the Expires HTTP Header within Mark Nottingham's excellent Caching Tutorial).

However, this weakness of the HTTP 1.0 Expires: ... header has been realized and remedied in HTTP 1.1, which introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires. (see Cache-Control HTTP Headers).

So concerning your use case (and in general), I'd strongly recommend resorting to a Cache-Control: max-age=... header for one year in the future first and only add Expires: ... for backward compatibility, if there is a specific reason to do so. In this case however, according to your question, you'll indeed have to adjust the value once in a while to avoid violating the HTTP 1.1 RFC, e.g. via a script targeting the S3 API.

  • Thanks for a great answer. One more quick question: do you know if "public" is necessary in the Cache-control directive, or is that the default? i.e. Cache-control: public, max-age=3600 Jan 25, 2012 at 17:30
  • 1
    It is not the default as such, rather cacheability depends on the context (e.g. default is private for HTTP authenticated requests) - the details are a bit complex, see What is Cacheable? and Response Cacheability, i.e. it's sort of implied in most scenarios, but concerning your use case it seems reasonable to add it, insofar you'd probably want to cache authenticated responses as well (if any)?! Jan 25, 2012 at 18:26
  • As usual, the summary in Mark Nottingham's Cache-Control HTTP Headers is actually much easier to wrap ones head around I think, please have a look at the explanation for public and particularly no-cache, which expands on the implications of the former. Jan 25, 2012 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.