tags:

views:

352

answers:

6

I've been learning JavaScript recently, and I've seen a number of examples (Facebook.com, the Readability bookmarklet) that use Math.rand() for appending to links.

What problem does this solve? An example parameter from the Readability bookmarklet:

_readability_script.src='http://lab.arc90.com/....script.js?x='+(Math.random());

Are there collisions or something in JavaScript that this is sorting out?

+4  A: 

Main point is to avoid browser caching those resources.

Rubens Farias
+1  A: 

This will ensure that the script is unique and will not cached as a static resource since the querystring changes each time.

Chris Ballance
+1  A: 

This is because Internet Explorer likes to cache everything, including requests issued via JavaScript code.

Another way to do this, without random numbers in the URL, is to add Cache-Control headers to the directories with the items you don't want cached:

# .htaccess
Header set Cache-Control "no-cache"
Header set Pragma "no-cache"

Most browsers respect Cache-Control but IE (including 7, haven't tested 8) only acknowledge the Pragma header.

scribble
A: 

Depending on how the browser chooses to interpret the caching hints of a resource you might not get the desired effect if you just asked the browser to change the url to a url it has previously used. (most mouse-over image buttons rely on the fact that the browser will reuse the cached resource for speed)

When you want to make sure that the browser gets a fresh copy of the resource (like a dynamic stock ticker image or the like) you force the browser to always think the content is newby appending either the date/time or a every-incresing number or random gargabe).

feihtthief
+11  A: 

As Rubens says, it's typically a trick employed to prevent caching. Browsers typically cache JavaScript and CSS very aggressively, which can save you bandwidth, but can also cause deployment problems when changing your scripts.

The idea is that browsers will consider the resource located at http://www.example.com/something.js?foo different from http://www.example.com/something.js?bar, and so won't use their local cache to retrieve the resource.

Probably a more common pattern is to append an incrementing value which can be altered whenever the resource needs to change. In this way, you benefit by having repeat requests served by the client-side cache, but when deploying a new version, you can force the browser to fetch the new version.

Personally, I like to append the last-modified time of the file as as a Unix timestamp, so I don't have to go hunting around and bumping version numbers whenever I change the file.

Rob
+1 very detailed, Rob, ty
Rubens Farias
I use revision numbers (svn gives an int, hg gives a uuid)
Jiaaro
@Jim: Yeah, it's all about not having to remember to change things. :)
Rob
A: 

There is a tool called squid that can cache web pages. Using a random number will guarantee that request will not be ached by an intermediate like this. Even with Header set Cache-Control "no-cache" you may still need to add a random number to get through something like "squid".

Philip Schlump