Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

It might be a good idea to encode, in the JavaScript source, some revision information.

With that information, the code can check to see if it matches the current revision that is encoded in the current webpage. This way it can display an information bar that tells the user to update their cache.

Hopefully this would cut down on the number of questions tagged [browser-cache].

share|improve this question
Yeah. Those 12 questions are really clogging up meta... ;-D – Adam Davis Feb 1 '10 at 19:53

Indeed, we already do. View source and see for yourself...

<script src="" type="text/javascript"></script>    
<script src="" type="text/javascript"></script> 

The problem is that certain proxies and browsers seem to ignore this version information in the URL.

share|improve this answer
I don't think you read the question very well. – GEOCHET Feb 1 '10 at 20:02
Jeff is saying that the browser should already detect that the version number has changed, and refresh its cache, without any extra intervention needed. – Ether Feb 1 '10 at 20:03
@Aether: And we are saying that obviously is not working very well, so why not just prompt the user? By doing the check described in the suggestion, you already know the browser/proxy has failed so there is no loss here. – GEOCHET Feb 1 '10 at 20:05
well, the version information doesn't need to be in the file, when it's effectively part of the filename (URL) the browser uses to retrieve it. – Jeff Atwood Feb 1 '10 at 20:06
I meant store it somewhere the JavaScript can access it, and to use it to notify the user of the discrepancy. – Brad Gilbert Feb 1 '10 at 20:07
That means extra, redundant code on every page load for every user. I'd rather treat the disease (why are proxies/browsers incorrectly caching unique URL strings?) than the symptoms. – Jeff Atwood Feb 1 '10 at 20:09
@Jeff: Let us know when you fix our browsers and proxies. kthxbye – GEOCHET Feb 1 '10 at 20:11
What @The sez: it's not part of the filename right now, effectively or otherwise - it's part of the URL, but a part that (apparently) is being ignored in some instances. – Shog9 Feb 1 '10 at 20:25
@shog9 what's scary is: if that is true, then the WHOLE INTERNET will be broken for these folks sooner or later -- if unique URLs aren't treated as unique sets of data by the browser, that's just.. terrifying. – Jeff Atwood Feb 1 '10 at 20:32

Instead of asking the user to flush his cache, why not do it for him?

<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script> 

And redirect to the correct file serverside?

share|improve this answer
The syntax used in Jeff's answer ought to be sufficient. Something else is going on if the browser is ignoring the version. – Ether Feb 1 '10 at 20:31
@Æther: it obviously isn't enough, as some proxies seem to be caching the file ignoring the change in the querystring. – perbert Feb 1 '10 at 20:43
That should be worrying though, as SO does on occasion use querystrings for... you know... queries. I think this is probably a useful stop-gap if the SO Team doesn't have the time or inclination to research the issue further, but unless they have a better understanding of the causes and scope of the problem it is a bit concerning. – Shog9 Feb 1 '10 at 20:52
it is a good idea but makes the build extra-complicated. Also, I tend to agree with Shog9 that there's a deeper problem here that is worrisome -- are browser/proxies incorrectly caching unique URLs? If so then that is a REALLY serious problem they need to diagnose / fix on their end. – Jeff Atwood Feb 2 '10 at 0:03

Or they could just version the script file names and side-step the whole issue. Not sure why scripts are being cached anyway, given that they already have the version number appended in the querystring...

Jeff elaborates on their use of this technique in another answer. JavaScript can already access the version information as it's stored in the URL of the JavaScript file - all that would be needed would be a variable in the file itself with this same version number.

But I think it's a lousy idea, a bad work-around for a poorly-understood issue. The scripts are updated frequently, and the current cache-control methods handle these updates just fine for most users most of the time - else the site would be perpetually crippled. If the SO team were to add code to manually check the version # on the client, they would be better off sending client and network information back to SO when the problem is identified, with the goal being to identify the root cause(s) of the problem.

share|improve this answer
Are we sure that this is the real problem? I don't see an error with the <script> tags that Jeff lists in his answer, but I'm far from an expert in this area. – Ether Feb 1 '10 at 20:11
@Æther: no... In fact, I rather suspect there's something else going on. – Shog9 Feb 1 '10 at 20:22

If this is easily achievable I would support this. Just the time spent in telling the same people over and over to clear their cache would make it worth it.

Maybe we could find a way to post another set of warnings if you have cookies/JavaScript disabled?

That would fix most of the issues you see here from people who cripple their browsers and then cry when the internet stops working.

share|improve this answer
There is already a popup bar that indicates when javascript is disabled. – Ether Feb 1 '10 at 19:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .