Force cache refresh after deployment

Kyle picture Kyle · Jan 20, 2012 · Viewed 54.2k times · Source

Is there a way to force a client's cache to reload an HTML file if you can't change the URI referencing that file (e.g., can't add a timestamp param)?

Here's my situation:

  • A plugin deployed to a 1000 users
  • That plugin loads example.com/page.html which calls on script.js
  • The resource URI example.com/page.html cannot be changed (w/o plugin updates)
  • page.html has been changed. I need to clear the old page.html from users' cache so the new page.html can load.

Any ideas? Htaccess? The PHP API that the old & new page.html call on?

Thanks!

Answer

rdlowrey picture rdlowrey · Jan 20, 2012

Well, if the page is already cached by a browser it's difficult to tell it not to use its cached version because it probably won't bother to check again before it determines its cached version is stale. You'll just have to send a snail-mail letter to all of your users informing them to press ctrl+f5 :)

There is a chance that the browser might at least try a HEAD request to check the modified timestamp before it serves up its cached version, though. In this case the following will help you out.

Browsers negotiate their content from your web server using HTTP standard headers. Going forward if you want to tell a browser not to cache a file, you have to send the appropriate HTTP headers. If you want to do this in PHP you can use the header function to send the appropriate HTTP headers to the browser:

header('Cache-Control: no-cache');
header('Pragma: no-cache');

If it has to be done via HTML you can do the following in your page header:

<meta http-equiv="Expires" content="Tue, 01 Jan 1995 12:12:12 GMT">
<meta http-equiv="Pragma" content="no-cache">

There is no way for you to be sure if the browser will honor your request that it not cache a page, however. There are some other things like eTags and whatnot but frankly I don't think that's going to help you out if the page is already cached.


UPDATE

From the HTTP/1.1 specification on Response Cacheability:

If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available).