3 ms·

I think you are over simplying. Look at http://www.mnot.net/cache_docs/ http://www.mnot.net/cache_docs/ for the nuances involved.

• cheald 16y ago
  I'm really not. max-age and the Expires header, properly set, will control caching at just about every possible step. If you refresh apple.com several times, you'll notice the max-age cycles down with each refresh, and the Expires header stays the same. They're obviously set up to cause the page to have a short maximum lifetime in both public and private caches, and in the case of a launch, it's not that hard to make sure that the old copy of the page expires at 11 AM PST or whenever you want your announcement to go live. Announce product, push deploy button on website, people hit website and browser requests a new copy of the page because its current copy expired at 10:59:59, and presto, it all magically works.
  • sghael 16y ago
    But that only solves for the case of predictable events. If you want to remain agile, and do deployments on an as-needed basis, then you need to cache bust with file naming or query parameters as I mention in other msg. Again, I'm pretty sure this is the preferred method of most web teams, and also appears to be what Apple is doing (atleast with a subset of their assets).
    • cheald 16y ago
      Assets, yes. Pages, no. Query strings for cachebusting CSS/images is pretty standard.