Cache Me Not

Today I worked on an interesting bug that required us to forcefully push out a new copy of a file to any client that connected to our web application. The file was a javascript file containing several functions which are used by our application, one of which was modified and is now used as a trigger for an important part of the application (don’t ask why). Clients to our application are the general public, so forcefully clearing caches was certainly not an option, but our solution might have been made easier if we were allowed to change the name of the file, or even the name of the function. Unfortunately other existing technical requirements did not permit this.

A quick google-later gave me enough evidence that header tags like <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> (for HTTP 1.0), <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE"> (for HTTP 1.1), and <META HTTP-EQUIV="EXPIRES" CONTENT="0"> would not be enough to trigger a refresh of the client’s versions. Some sites described that writing out values in the HTTP-Headers might also work, but I wanted to avoid it for not being a very simple solution.

In the end, the solution we deemed acceptable was to simply add a query string to the end of the file so that clients would be tricked into thinking that it was a new file, turning something like: <script src="/scriptForRefresh.js" type="text/javascript"/> into: <script src="/scriptForRefresh.js?forceMeTo=refresh" type="text/javascript"/>

2 Replies to “Cache Me Not”

  1. I’ve used that trick before with client logos (images). If you want to save space, you can just use something really short like:
    <script src="/scriptForRefresh.js?0" type="text/javascript"/>

  2. I didn’t read this post because it was so technogeek. I did look at the timestamp to see if it was a previously posted geek entry or if it was new. It took me a full 5 seconds to realize that 5/1/2005 means “January 5th 2005” in non-American. Is it time to go home yet?

Comments are closed.