JavaScript cache control

Preventing stale scripts in client cache

[Greywolfe]

What I would like to know are methods to insure that a .js file cached by the browser is the correct one and hasn't been altered on the client side to work differently than intended.
I know from experience, that you can alter js files in the cache and that the file won't update if the file size remains the same size.

jdMorgan suggested "You should set up your server to send appropriate cache-control headers for each kind of content on your site."

But not really sure on how to do this, and to do this for specific files.

I don't want the user to download this file everytime, cause the load on the server would go through the roof, but only when the file has been altered.

Please let me know your thoughts, and if you have questions about the situation, just ask. :)

Jim

Thanks jdMorgan :)

[jdMorgan]

Jim,

Here's a recent thread [webmasterworld.com] to get you started. See the second half of msg#2. Set your JS files to expire after an hour/day/week if you want to do it by time, or set your cache-control header to "no-cache, must-revalidate" as discussed there, or do both.

Jim (2)

[Greywolfe]

Ok, seems to make sense what I've found. But I've been doing some testing with this, and while the headers and stuff go through. It still doesn't seem to be able to catch if the cache file is changed, but still remains the same size. Any ideas?

BTW, the info in the other post will be very useful though. Including the rewrite info. Thanks :)

[jdMorgan]

Size has nothing to do with it. If you examine your server logs, you should see requests for the file returning a 304-Not Modified response and zero bytes transferred if the client already has a current copy of the script. Then if you re-upload the file to your server, the next request from each client should result in a 200-OK response and a full file reload.

If that's not working, then something's wrong in your code.

Use the Server Headers [webmasterworld.com] checker if your logs don't update fast enough for effective testing. You should see each .js file marked with a header reading 'Cache-control: "no-cache, must-revalidate"' or whatever you specified, plus the Expires time if you set that.

You should also see a "Last-Modified: " header, giving the date and time of your most recent upload. This is the header that the client and server use to determine whether a newer version exists; The client sends a CGET (conditional GET) saying, send me the file If-Modified-Since, and gives the date of the copy it has. The server compares the date of it's copy to the date given by the client. If the server's copy is the same date as the client's, the server responds with 304-Not Modified, and the transaction ends. If the server has a newer copy, it send it along with a 200-OK status.

Also note that the client must know how to do this, and that some clients will have this capability disabled. However, when this happens the usual result is that the script will be fetched every time the page that calls it is reloaded if the cache-control header is set to "no-cache, must revalidate". All modern browsers -- and several robots -- are capable of supporting this 'protocol'.

Jim

[Greywolfe]

arghh...hope there wasn't confusion, but I'm talking about the copy in the clients cache being altered, I'm not changing the js files on the server. I'm trying to prevent users from changing the version in there browser's cache to change how the website runs.

It's actually the opposite problem of stale scrits in client cache. It's more recent scripts in client cache that are a problem.

[jdMorgan]

Well, you'll have to explain that one more, too...

Most users have no idea how to do this, and it's something I've never considered (or tried). You can mark the files as 'Cache-control: "no-store"' to force a reload from your server each time the file is called, but I suppose even that could be hacked by a determined user, so I fail to see the point.

If you're talking about a user saving the page (and everything that goes with it) to disk, and running a local copy and modifying your script, then you'll need some active client-side scripting to prevent that from working.

Jim

[Greywolfe]

Well, the users don't copy the whole page, cause that is quite easy to prevent from working. But quite a few users, will modify the cache file to perform the tasks they want to repeat, and continue to use the normal website, but with altered cache files. The no-cache and no-store headers do prevent that quite well. But the cost is resending 1/2 dozen js files upto 2500 times an hour for each of 150-200 users. Not quite the type of load I'd like to see on bandwidth. lol

Ideal would be a setting, that says if cache is newer, then reload. I've considered periodically having the js files on the server update their last modified, but that puts a heavy hit on the server when that happens. :(

Interesting problem, isn't it? lol

[jdMorgan]

> periodically having the js files on the server update their last modified, but that puts a heavy hit on the server

Yeah, updating the last-modified date is easy with a cron job and a shell 'touch' command, but the reloads that it will cause will certainly load your server down.

I'd suggest taking the functions that are causing problems out of your client-side code, and moving that functionality server-side where you can control it. Sorry, that's the best I can come up with.

Jim

[Greywolfe]

Thank you sir. I appreciate your help. And I did learn a few things that will be quite helpful as well. So it's all good.

Jim