current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
up vote 29 down vote favorite
5

I'm using Amazon S3 to serve static assets for my website. I want to have browsers cache these assets for as long as possible. What meta-data headers should I include with my assets

Cache-Control: max-age=???
share|improve this question
    
the possible max-age value is dependent on browser/version and any proxy in the way... AFAIK there is not real standard/spec so any value would be a guess... – Yahia Aug 15 '11 at 23:02
up vote 34 down vote accepted

Generally one year is advised as a standard max value. See RFC 2616:

To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.

Although that applies to the older expires standard, it makes sense to apply to cache-control too in the absence of any explicit standards guidance. It's as long as you should generally need anyway and picking any arbitrarily longer value could break some user-agents. So:

Cache-Control: max-age=31536000
share|improve this answer
up vote 15 down vote

Consider not storing it for "as long as possible," and instead settling for as long as reasonable. For instance, it's unlikely you'd need to cache it for longer than say 10 years...am I right?

The RFC discusses max-age here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3

Eric Lawrence says that prior to IE9, Internet Explorer would treat as stale any resource with a Cache-Control: max-age value over 2147483648 (2^31) seconds, approximately 68 years (http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx).

Other user agents will of course vary, so...try and choose a number that is unlikely (rather than likely!) to cause an overflow. Max-age greater than 31536000 (one year) makes little sense, and informally this is considered a reasonable maximum value.

share|improve this answer
    
I'm actually looking for the specific headers to send. I have a mechanism built into my website to change the url of the file to point to a different filename if i need to make a change and have visitors see it. I just need an example of the specific headers to send to get browsers to cache these assets indefinitely. – Casey Flynn Aug 15 '11 at 23:23
9  
Cache-Control: max-age=31536000 will cache it for 1 year, which is the max-recommended. – EricLaw Aug 15 '11 at 23:53
1  
@Geoffrey: I think you're confused about what Casey is building. He's simply saying that he'll change the URL he references in his markup when the version changes. This is a best practice used by most top sites. – EricLaw Aug 16 '11 at 4:10
    
@Geoffrey Are you sure it's "over 2147483648"? I'd thought it was "over 2147483647"? – Pacerier Oct 13 '12 at 15:53
up vote 1 down vote

The people who created the recommendation of maximum 1 year caching did not think it through properly.

First of all, if a visitor is being served an outdated cached file, then why would it provide any benefit to have it suddenly load a fresh version after 1 year? If a file has 1 year TTL, from a functional perspective, it obviously means that the file is not intended to be changed at all.

So why would one need more than 1 year?

1) Why not? It doesn't server any purpose to tell the visitors browser "hey, this file is 1 year old, it might be an idea to check if it has been updated".

2) CDN services. Most content delivery networks use the cache header to decide how long to serve a file efficiently from the edge server. If you have 1 year cache control for the files, it will at some point start re-requesting non-changed files from the origin server, and edge-cache will need to be entirely re-populated, causing slower loads for client, and unnecessary calls to the origin.

What is the point of having max 1 year? What browsers will choke on an amount set higher than 31536000?

share|improve this answer
1  
1 year is an eternity in internet age. Plus if you take caching seriously you would handle (in addition to cache-control) the last-modified and/or etag mechanism. So even those re-requests a year later won't harm the bandwidth (304 not modified) – redben Apr 20 '15 at 10:53
    
1 year is not an eternity when your images are NEVER changed (like most images on the internet), and when you don't want a CDN to refresh files from the origin (which would be pointless). As for last-modified/etag, of course that initiates a request and dialog between client and server, just to find out what we already know "yup, its still ok to serve the cached file". Your argument is basically "1 year is an eternity on the internet", which doesn't serve anything productive. I have set 10 years expire on images, which simply serves a better end result. – suncat100 Apr 21 '15 at 16:17
2  
Oh and there is also default browser cache size. Would any cached asset survive a year in a browser cache ? I don't know. – redben Apr 22 '15 at 12:16
    
Extremely unlikely. Something which further proves the pointlessness of setting "1 year" when it serves no other purpose than attempting to cache an item "forever" or "as long as possible" ... – suncat100 Apr 23 '15 at 13:22
    
It isn't about the browser caching it. It is about intermediate proxies caching it such as Akamai and Varnish and Google's mobile proxy etc. – Elijah Lynn Dec 16 '15 at 21:38

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.