Web apps + AJAX = distribution problem?

Thu, 08 Sep 2005 comments

One of the large problems with desktop software was keeping the installed base up to date. Even Microsoft has had issues keeping their computers patched. And supposedly this is fixed with web apps. But as the alpha service renkoo observed about lost updates, you still have to be careful.

If you are having problems with Renkoo today, it is likely that you have the old version cached in your browser.

You see, browsers cache linked files such as javascript and CSS stylesheets. This is great because you can have large scripts/stylesheets only downloaded the first time a visiter hits your site. The browser does NOT check with the server if it considers resources to be fresh. This implies the instant you start changing javascript or css in linked resources, you are potientally causing presentional errors, or worse yet, old ajax calls could cause data integrity problems.

Thankfully there is a very simple fix. Always append the version number to the filename of linked resources (perhaps using the version number from your code repository). Since your HTML file links to a new file the new version will be downloaded. It is a simple fix, but easy to forget as you probably hit refresh many times when you are working on your projects, which will download a fresh copy of all linked resources.

Responses to "Web apps + AJAX = distribution problem?"

Thu, 08 Sep 2005 Phil says:
Heh; I was halfway through reading this, thinking to myself, "all you have to do is reference the version number in the file name", and then I see that you mention that. Unfortunately, I don't do that myself yet. Time to go make some changes!
Thu, 08 Sep 2005 Alex says:
What implications would this have when using a revision control system such as Subversion. Am I correct that you are essentially renaming the file(s) every time you make a functional change?
Thu, 08 Sep 2005 Jesse Andrews says:
Alex, Well, this requires an extra step. What I did was create a script that modifies my layout file (the one file that links to the css/javascript) and the actual javascript/stylesheets. Then I run this script only on the production checkout (and do not check these changes in) I do not recommend modifying the file names in your revision control system.
Thu, 08 Sep 2005 Alex says:
I have been thinking about this some more. Can we not just send suitable HTML headers to prevent dynamic pages from being cached in the first place? I am by no means finding fault with your method, I am just looking for an alternative more suited to my own environment.
Thu, 08 Sep 2005 Jesse Andrews says:
yeah, we could change it so the headers on the javascript/css say not to cache them. And this wouldn't bad for a site that was completely ajax (but make sure you don't break the back button and try to make URLs be identifiers. . .) Downloading all the javascript each time would suck for both you and the end user if the user changes their document.location with regular frequency. Another solution that may or may not be easier - create a directory that is just a new sym-link to the real location for css/javascript with each new version, then prepend the location for the resources with that version #. In my mind I do want caching whenever possible. The only time caching becomes an issue is those few times you actually update the files.
Thu, 08 Sep 2005 Abe says:
Funny, I just implemented this last week for Jot Live, after I got tired of telling my alpha testers to shift-refresh. I added some lightweight code in my template to check the modified time of all css/script files, and link to them in the form "filename?mtime". The extra argument is ignored by the web server, so you don't have to rename the files, and since its based on the modification time the link only changes when the file does.