Yes, I know headers are better. But we've all dealt with that system where we want something to be cached (HTML only in this case as it's a tag) like so:
<meta http-equiv="Cache-Control" content="max-age=200" />
It does not appear to work when I test it casually. Is there any way to get a document to be cached for, say, 200 seconds without access to an .htaccess file or a programming language?
I know it's not ideal, but it's occasionally functional. I was hoping there would be a way to denote a particular directory with some sort of simple rules in the HTML cache manifest. No dice.
IE has partial (and buggy) support for using a META tag to prevent caching, but this doesn't allow you to specify a non-zero freshness lifetime.
Specifying the freshness lifetime using the Cache-Control response header is absolutely the right way to go.
Related
Every time i update my website system UI/Jquery,
users complain that things are not working for them and that they have bugs.
Users are internet/computer dummies so they don't know how to clear the cookies or the cache of the browser, so i need to connect to each one of their computers and do it myself.
I spend lots off hours doing it and they always complain.
Some of the users use Chrome, some Firefox.
Googled and found no solution for this.
Is there any client code operation that will command the browser to clear its cache
or even pop up browser window which will ask user to confirm the clear?
Regarding cache clearing: No, there isn't.
What you can do, however, is configure your web server to correctly serve expiration and cache validity headers for your content. (How to do this depends on your web server.)
You can also use "cache busting" versioned URLs. Instead of using, let's say,
<script src="script.js">
you can "version" the URL like this:
<script src="script.js?2012-12-03-13-06">
<!-- or instead of dates any other versioning scheme you like -->
and when said script is updated, also increment/change the query parameter accordingly. This should cause browsers to consider the script as new as the URL isn't found in the cache.
document.cookie = '';
With browsers that allow entering js code in the address bar you can simply make a shortcut lets say a favourite with the following code as a url:
javascript:document.cookie = '';
If you'd like to clear cache you can use meta tags not to cache the site, though caching is conciderable.
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
I've implemented server independent eTags on my site and I'm now looking at adding expires headers to prevent most of the 304 requests.
I'm concerned about using long expiration headers since it makes it tough to force a refresh if you need to update content. And I'm also not a big fan of cluttering my code with versioning query strings like:
<link rel="stylesheet" type="text/css" href="/style.css?version=X" />
So I'm thinking about setting the expiration header to something short like 10 minutes for almost everything. This way, I only have a possible 10 minute window of stale content, yet for a normal browsing session, I'm going to stop most of the 304s. And even if they do stay longer, I'll just be serving one 304 every 10 minutes unless the content changes.
It seems pretty elegant, yet I've seen a lot of sites using the above versioning querystring method, and even google's mod_pagespeed has an option to more or less do versioning automatically, so I'm just curious if this is a solid appropach or if I've missing something that makes it impractical.
Thanks
And I'm also not a big fan of cluttering my code with versioning query strings like:
Why? No one sees it, and you can easily automate it - have your CMS or framework automatically append the file's modification time or md5 hash to the link tag.
I'm using Play Framework (v1.1.1) and I have a doubt about the #{cache} tag.
I suppose the question would be "when should I use it?" but I think it's quite generic.
So besides that, I would like to know if someone has checked its behaviour with Javascript. I understand that it will cache the output of other tags embedded in its body, but it will also cache Javascript? More specifically, if I include some script tags that reference external resources (like a CDN), the file will get cached too or only the tag?
The purpose of the Cache tag is to cache the output that the server sends to the client. Javascript, images and any other information that is contained within the code sent to the client side is not cached, unless specifically told to do so by the headers set in the tag of your HTML.
By default, Play (if you extend the main.html) does not specify any cache-control headers, so therefore your scripts will be cached based on the browsers standard caching policy. This should be "no-cache" according to the http spec, but I am doubtful of whether this is the case.
I am trying to get Opera to re-request a page every time instead of just serving it from the cache. I'm sending the 'Cache-control: no-cache' and 'Pragma: no-cache' response headers but it seems as if Opera is just ignoring these headers. It works fine in other browsers - Chrome, IE, Firefox.
How do I stop Opera from caching pages? What I want to be able to do is have Opera re-request a page when the user clicks the Back button on the browser.
As a user, I absolutely detest pages that slow down my history navigation by forcing re-loads when I use the back button. (If the browser you use on a daily basis paid attention to the various caching directives and let them affect history navigation the way you want as a developer you'd probably notice some sites slowing down yourself...)
If you have a very strong use case for doing this I'd say your architecture might be "wrong" in some sense - for example, if you're switching between different "views" of constantly updating data and thus want to enforce re-load when users go back perhaps using Ajaxy techniques for loading the constantly changing data into the current page would be better?
Opera's implementation is on purpose - "caching" is seen as conceptually different from "history navigation", the former is more about storing things on disk and between sessions, the latter is switching back to a temporarily hidden page you just visited, in the state you left it.
However, if you really, really need it there is a loophole in this policy that enables the behaviour you want. Sending "Cache-control: must-revalidate" will force Opera to re-load every page on navigation, but only if you're sending the page over https. (This is a feature requested by and intended for paranoid banks, it slows down way too many normal sites if applied on http).
It sounds like your problem is related to this answer. After testing your header and the suggested headers, I could only reproduce your expected behavior in Internet Explorer.
SIMPLE SERVERSIDE CACHE CONTROL WITHOUT HEADERS OR FRONTEND SCRIPTS
Zero Dependency, Universal Language Edition
You can force re-caching globally without using a header by appending an md5 or sha1 checksum to your filename.
That way it will cache if it is an exact match, and otherwise treat it like a new resource.
Works in all browsers
Validates as strict HTML5 (originally did not, but this has been updated. Untested for XHTML, but probably not valid for that)
Does not require extra headers
Keeps frontend concerns and backend concerns nicely decoupled.
Does not require client side sanity checks or source validation.
Anything that can print html can do this consistently, including static content
If not static, easy to extend runtime control to end users (with authentication, if desired) that allows for simple page flags to determine minified, prettified, or debug source being returned.
Entirely encapsulates client cache control in the content serving mechanism, which makes things super simple to maintain.
As a side perk, introduces versioned client-side caching automatically by deferring to the checksums the browser has cached, which can be useful if you have alternate versions and need to unit test a release package to determine it's minimum stable dependency versions or something.
You don't ever have to fiddle with your browser to get the caching not to interfere with your development process again.
This approach also can be used for versioned images, video, audio, pdfs, etc. Pretty much any resource that is served as static data will operate similarly, cache on the first request for the content, and persist automatically without further consideration if the file does not change.
This is RFC valid markup. Notice the script and link tags have a get string:
?checksum=ba411cafee2f0f702572369da0b765e2
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Client Cache Control Example</title>
<meta name="description" content="You're only going to cache this when the content changes, and always when the content changes.">
<meta name="author" content="https://stackoverflow.com/users/1288121/mopsyd">
<!-- Example Stylesheet -->
<link rel="stylesheet" href="css/styles.css?checksum=ba411cafee2f0f702572369da0b765e2">
<!-- Example Script -->
<script src="js/scripts.js?checksum=ba411cafee2f0f702572369da0b765e2"></script>
</head>
<body>
</body>
</html>
The GET string ?checksum=ba411cafee2f0f702572369da0b765e2 refers to either an MD5 or SHA1 hash of the filesize of the resource. It can be obtained through a command line, language construct, or by hashing it from the value of the Content-Length: header. You then construct your href or src attribute by appending it as a GET string to the filename.
This browser will interpret these as distinct, and cache separately.
The server will ignore the GET parameter if it is a static resource, but if it is served dynamically, then the GET parameter will be available to the interpreting language.
This means that whenever that hash changes in the links, the browser will cache that specific version independently one time, and then keep it until forever, or Expires: goes by, whichever is sooner.
Since the checksum is a direct reflection of the filesize, you can set Expires: to forever and it doesn't make much difference. You will still see your changes immediately as soon as that file changes even a single byte.
Generate your css or js source with whatever utilities you normally do.
Run an md5 or sha1 checksum on the filesize at runtime if you are serving dynamically, and at compiletime if you are generating static content (like ApiGen docs, for example).
Serve the normal file with the hash as a GET string appended to the filename (eg: styles.css becomes styles.css?checksum=ba411cafee2f0f702572369da0b765e2)
Any change in the file forces a recache, which means you see the real value reflected immediately.
Optional, but rad: An additional benefit of this approach is that you can easily set up a dev GET flag, which will make ALL frontend source resolve to prettified dev source with any of your own custom debug functionality enabled, or use it to interpret versioning flags. You can do a redundant check to make sure that flag is only passed from a known development IP address, proxy authentication, etc. by the server and otherwise is not honored if you need it secure. I usually divide my frontend source up whenever possible similar to this:
This is what it is doing on live right now (minified production, cached, default, ?checksum=ba411cafee2f0f702572369da0b765e2).
This is what it ought to be doing on live right now, prettified enough for me to read (prettified production, never cached, ?debug_pretty_source=true).
This is what I use to figure out what isn't doing what it ought to on live if it exists in both of the previous (prettified with debug enabled, never cached, ACL/whitelist authorized, ?debug_dev_enable=true or similar).
You can apply the same principle to package releases by using version numbers instead of checksums, provided your versions don't change. Checksums are less readable but easier to automate and keep in sync with exact changes, but version suffixes are useful for testing package stability also, provided the version number reflects an immutable resource.
Found this whilst searching for solution. No joy, so wrote some javascript to solve the problem which may be of use to others.
In <HEAD> above any other javascript:
<script>
if( typeof(opera) != 'undefined' ) { // only do for Opera
if (window.name == 'previously_loaded') { // will be "" before page is loaded
alert('Reloading Page from Server'); // for testing
window.name = ''; // prevent multiple reload
window.location.reload(true);
}
}
</script>
Now change window name so Opera detects it on subsequent load from cache:
window.name = 'previously_loaded';
Insert this line in one of your js blocks that wont be executed during “window load” causing infinite reload. For me there was no need to refresh the page unless someone has exited by a link, so I just added it to my onclick/onunload function.
Before and after demos here with a few more notes. I intend to add it to my blog. I've only a few late versions of Opera, so I would appreciate some tries of the demo before I get egg on my face.
Edit: Just realised that if a later visited site changes window name (its persistent) then back-tab reload wont happen. Just alter above if statement to:
if (window.name != "") {
Demo worked fine when open in multiple tabs; but I vaguely recollect that window names should be unique; so I've altered the demo to generate a unique name.
window.name = new Date().getTime();
I have a web page that always needs to stay current. I do not want the browser to cache it. To that end, this meta tag is embedded with the page:
<meta name="Expires" content="Tue, 01 Jun 1999 19:58:02 GMT">
However, some browsers seem to ignore it. Chrome is particularly bad at it, though other browsers tend to do the same thing.
When I pick the page from the bookmarks bar, most of the time, it doesn't even hit the server, just loads it from cache. If I then press F5, it does go to the server and fetch a new copy.
Am I missing something simple? I thought the expires meta tag is the way it's done.
This is happening on an IIS 5.0 on Windows 2000.
Bottom line: looks like meta tags inside the HTML code pretty much do nothing. However, setting the expires tags within the HTTP does the trick nicely.
Send your expires headers using your server. Specifically, if you're using apache, look at this:
http://httpd.apache.org/docs/2.0/mod/mod_expires.html
This should help you:
<meta http-equiv="cache-control" content="no-cache" />
You can also configure the static content cache mechanism through IIS; you can learn how to do so here: http://support.microsoft.com/kb/247404.
<meta http-equiv="Cache-Control" content="private, no-store" />
Is really ALL you need, as stated here https://youtu.be/TNlcoYLIGFk?t=654 by Andrew Betts, elected W3C TAG member.
Using this, you will not need pragma or expires. Infact, the above will overwrite the Expires command.
You want to send an Expires header set to a date in the past (like your Meta tag).
Expires is the most widely respected cache header, but you can also use things like Last-Modified, or Etags to get more specific control.
Meta tags are a somewhat outdated means of setting caching protocols, and most of the meta cache control properties are fairly deprecated (e.g. NO-CACHE). A lot of user agents ignore them.
There is a great article I used to read about browser caching ans caching in general :
http://www.mnot.net/cache_docs/
It explains in high details what works and what does not, what is best to do.
In summary there are a lot of ways (html tags, HTTP headers) and types of cache (browser proxy, gateways)
Send Cache-Control: no-cache to the client within the response headers.
Please specify what platform are you using to make a better response.