Should web-browsers allow to clear(expire) cache programmatically?

I do not think it is this easy. One problem I can see is that it is not just the browser cache. Your files can be cached in many places along the way from your server to the browser (clients).

Some of the browsers can still use the old version, and the answer to the question which one is cleared and what version is supposed to go to this particular client becomes really uncertain really fast.

Hehe, well, as far as us developers are concerned, of course! On the other hand, cache is there to facilitate the user's experience in terms of responsiveness. It is our responsibility to work-around all these nuisances and protect the user in a shell of ignorance and all-is-wellness.

1 Very well stated! – Mike Clark Oct 23 '09 at 19:56 1 The problem is that browsers made it impossible for us to "work-around all these nuisances". If browsers stop supporting JavaScript one day, will you say that it's our responsibility to create rich web user interface without use of JavaScript?

– alpav Oct 29 '09 at 14:46.

Set reasonable cache expiration intervals, and schedule your updates to match those, and it should be ok as it is.

– Jeff Meatball Yang Oct 23 '09 at 19:58 By using component loader and coding web app as one page application. See my more detailed response on top. – alpav Oct 29 '09 at 14:51 1 @alpav Not a very SEO-friendly aproach there, makes indexing and navigation a bit difficult.

– luvieere Oct 30 '09 at 9:40 I agree about SEO. It does not have to be one page app, the idea is that every file does not have to ever expire except the list of updated files. If main loader is in expired list then whole app reloads.

Users should never be required to clear cache manually or click refresh to get fresh software version. – alpav Nov 2 '09 at 16:59 "schedule your updates" is the problem that prevents developers from quick painless updates. Schedule is painful because once you updated there is no way to update again until next scheduled point of time and if you've made mistake there is no solution to fix it.

– alpav Feb 22 '10 at 14:25.

I don't think what you suggest is necessary or desirable. The client-side cache should be controlled by the user, not by you (the data/code provider). If the user wants a better way to manage his "Temporary Internet Files", then that's up to the browser developers, but I think you should not have a say in how it is managed.

For all intents and purposes, you only need to say, "this data/code is usable until X date", "this data/code is usable until Y version", or "it's never usable again". Excellent cache control strategies can already be setup by using the existing HTTP headers (Cache-Control, ETag, etc. ). If you want something to be "forced" to be refreshed, you can always add a querystring with the date on it.

This is not really a hack, as you suggest, because you are saying, "get me the version of the file as of this date"... and your server has all the freedom in the world to refresh the caching policy: return "302 redirect" to the non-querystring version, or send down new headers, etc. Edit: I can refine my idea from above: You can use a path or querystring to identify the "current" version: somedomain.com/somepath/current/yourfile.js The "current" URL can be setup to give a 302 redirect to a particular version of yourfile. Js, while also telling the browser never to cache the current version: 302 Moved Temporarily Location: /somepath/v3.2.3/yourfile. Js Cache-Control: no-cache; This allows your "loader" HTML to include Javascript that decides to use a certain version.

1 302 redirect is interesting solution if it works without duplicating files in browser or proxy cache. But it still must duplicate URLs inside cache to avoid sending request every time page is loaded. Also it requires making dynamic references (URLs with querystring parameters) when my idea allows to keep static references just like they are on most web pages today.

– alpav Nov 3 '09 at 15:45 1 I disagree that developers "should not have a say in how it is managed". Developers have a say already because they can set immediate expiration or set indefinite expiration and generate tons of unique links and overload any local or proxy cache with garbage. I see that I made mistake in my question saying "clear cache programmatically" instead of "expire cache programmatically", which is what I really meant.

– alpav Nov 3 '09 at 15:47.

They theorically do, with cache params in the header section and meta parameters (google meta no-cache, PHP/ASP no-cache) like cache-expires, the date that should expire etc I agree that this is weird in most, if not all, browsers. Sometimes it works, sometimes it doesn't or takes more time to clear the cache for some reason but would be nice to have that option in the script, like a javascript or something directly on the tags, like img src="blah. Jpg" expires="my_blah_last_edited" it could be better, true.

Attribute expires="my_blah_last_edited" would be desirable only if I can change that attribute dynamically and have browser react on it immediately by reloading the file. If it remains static, requiring programmer to predict next deployment date&time, it does not solve deployment problem. – alpav Oct 29 '09 at 15:24.

I imagine there are great security concerns. You have anonymous and remote web-pages telling local a client to delete files on the client machine - this has all sorts of potential for disaster. Would you trust IE to do this?

It just sounds too risky. There's a big difference between a directive to not cache something in the first place and a directive to delete something already in existence from the cache.

No, there are no security concerns. Pages will not tell which file in which folder to delete, they will tell which URL to expire immediately. How setting immediate expiration on any URL after it's loaded can be security concern?

– alpav Oct 29 '09 at 15:22.

Because that exhausts caching resources if number of updates is significant. – alpav Oct 29 '09 at 15:15.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.