4

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].

Improve this question
1
  • 3
    Yeah. Those 12 questions are really clogging up meta... ;-D
    – Pollyanna
    Feb 1, 2010 at 19:53

4 Answers 4

Reset to default
4

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

<script src="http://sstatic.net/mso/js/question.js?v=6196" type="text/javascript"></script>    
<script src="http://sstatic.net/mso/js/tageditor.js?v=6016" type="text/javascript"></script>

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

Improve this answer
9
  • 1
    I don't think you read the question very well.
    – GEOCHET
    Feb 1, 2010 at 20:02
  • 2
    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, 2010 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, 2010 at 20:05
  • 1
    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, 2010 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, 2010 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, 2010 at 20:09
  • @Jeff: Let us know when you fix our browsers and proxies. kthxbye
    – GEOCHET
    Feb 1, 2010 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, 2010 at 20:25
  • 3
    @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, 2010 at 20:32
2

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

<script src="http://sstatic.net/mso/js/question-6196.js" type="text/javascript"></script>
<script src="http://sstatic.net/mso/js/tageditor-6016.js" type="text/javascript"></script>

And redirect to the correct file serverside?

Improve this answer
4
  • 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, 2010 at 20:31
  • 1
    @Æther: it obviously isn't enough, as some proxies seem to be caching the file ignoring the change in the querystring.
    – perbert
    Feb 1, 2010 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, 2010 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, 2010 at 0:03
2

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.

Improve this answer
2
  • 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, 2010 at 20:11
  • 1
    @Æther: no... In fact, I rather suspect there's something else going on.
    – Shog9
    Feb 1, 2010 at 20:22
0

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.

Improve this answer
1
  • 1
    There is already a popup bar that indicates when javascript is disabled.
    – Ether
    Feb 1, 2010 at 19:56

You must log in to answer this question.

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