views:

45

answers:

2

We recently started using SVN Keywords to automatically append the current revision number to all our <script src="..."> includes (so it looks like this: <script language="javascript" src="some/javascript.js?v=$Revision: 1234 $"> </script>). This way each time we push a new copy of the code to production, user caches won't cause users to still be using old script revisions.

It works great, except for IE6. For some reason, IE6 sporadically acts as though some of those files didn't exist. We may get weird error statements like "Unterminated String Literal on line 1234," but if you try to attach a debugger process to it, it won't halt on this line (if you say "Yes" to the debugger prompt, nothing happens, and page execution continues). A log entry for it shows up in IIS logs, indicating the user is definitely receiving the file (status code 200, with the appropriate amount of bytes transferred).

It also only seems to happen when the pages are served over https, not over standard http. To further compound things, it doesn't necessarily happen all the time; you might refresh a page 5 times and everything works, then you might refresh it 20 more times and it fails every time. For most users it seems to always work or else to always fail. It is even unpredictable when you have multiple users in a corporate environment whose security and cache settings are forcibly identical.

Any thoughts or suggestions would be greatly appreciated, this has been driving me crazy for weeks.

A: 

I think this is a very clever idea. However, I think the issue could be related to the spaces in the url. Technically, the url should have the spaces encoded.

See if you can customize the keywords in SVN to generate a revision number without special characters.

Jesse Weigert
The browser is escaping the special characters ($, :, and space) before making the request.
MightyE
Which browser(s)?
Milen A. Radev
+1  A: 
  1. Check your log with fiddler2 to make sure the browser request the page, and do not use the cache instead. Also check the URL of the JS script and the header returned.
  2. Are you using GZip? There has been issues reported with it.
  3. I would suggest testing using Internet Explorer Application Compatibility VPC Image. That way, you can do your tests with a 100% IE6, and not one of those plugin that claims to simulate IE6 inside another browser.
Thierry-Dimitri Roy
Fiddler2 as well as the IIS logs indicate that the request is going through and being responded with status code 200, with the appropriate number of bytes being transferred.Yes, gzip compression is in place. This may be the culprit and bears additional investigation, but if so I'm not sure why not having `?v=$Revision: 1234 $` on the URL has never given us problems.
MightyE