Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
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 –  DisgruntledGoat Jan 25 '12 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)?! –  Steffen Opel Jan 25 '12 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. –  Steffen Opel Jan 25 '12 at 18:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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