It seems that IE6 ignores any form of cache invalidation sent via http headers, I've tried setting Pragma to No Cache and setting Cache Expiration to the current time, yet in IE6, hitting back will always pull up a cached version of a page I am working on.
Is there a specific HTTP Header that IE6 does listen too?
Cache-Control: private, max-age=0 should fix it. From classic ASP this is done with Response.Expires=-1.
Keep in mind when testing that just because your server is serving pages with caching turned off doesn't mean that the browser will obey that when it has an old cached page that it was told was okay to cache. Clear the cache or use F5 to force that page to be reloaded.
Also, for those cases where the server is serving cached content it you can use Ctrl+F5 to signal the server not to serve it from cache.
You must be careful. If you are using AJAX via XMLHttpRequest (XHR), cache "recommendations" set in the header are not respected by ie6.
The fix is to use append a random number to the url queries used in AJAX requests. For example:
http://test.com?nonce=0123
A good generator for this is the UTC() function that returns a unique timestame for the user's browser... that is, unless they mess with their system clock.
Have you tried setting an ETag in the header? They're a pretty reliable way to indicate that content has changed w3c Spec & Wikipedia
Beyond that, a little more crude way is to append a random query string parameter to the request, such as the current unix timestamp. As I said, crude, but then IE6 is not the most subtle of beasts
see Question: Making sure a webpage is not cached, across all browsers. How to control web page caching, across all browsers? I think this should help out with your problem too.
Content with "Content-Encoding: gzip" Is Always Cached Although You Use "Cache-Control: no-cache"
http://support.microsoft.com/kb/321722
You could also disable gzip just for IE6
A little note: By experience I know that IE6 will load Javascript from cache even if forced to reload the page via Ctrl-F5. So if you are working on Javascript always empty the cache.
The IE web developer toolbar can help immensely with this. There's a button for clearing the cache.
Related
We have a page that makes AJAX calls to get a JSON file. The JSON file has a 'max-age=60' header.
On Firefox, the JSON file is incorrectly cached by BFCache beyond the 60 seconds specified by caching header. What is worse is that force-reloading (Shift+F5) doesn't help, as the JSON file is not retrieved from the server anymore.
This is a bug in Firefox, opened one year ago and still unresolved: https://bugzilla.mozilla.org/show_bug.cgi?id=1055024
Answers to this question How to force Firefox to bypass BFCache for Angular.JS partials? mention some workarounds that involve clearing the full cache or installing extensions. We have millions of users and it's not practical for us to ask them all to go through these steps.
Also, setting a 'unload' event in the page seems to disable BFCache completely for the page. This is also not an optimum solution for us, because we would like the whole page to benefit from BFCache speedup, and still see fresh JSON content honoring the max-age=60 header.
Does anyone know if there are specific caching headers that will hint BFCache NOT to keep this particular file and fetch it from the server once the max-age period has elapsed?
We have a web application.
Until now we had no real cache handling strategy.
When we had a new version of certain JavaScript files, we instructed our users to clear their browser cache.
Now we want to change this.
Up to this date our starting page was "start_app.html".
In our effort to implement our cache busting strategy we want to ensure that the browser will NOT cache our starting page.
We will change the extension from ".html" into ".php".
It seems that the browser has an array of extensions, when he ALWAYS fetches a fresh copy from the web server, like "php", "asp", and so on.
Is this true and which extensions are these?
Thanks alot in advance
Please don't rely on incorrect browser behavior to not cache your page. Instead, use this header:
Cache-Control: no-cache, no-store
This page has all the details as to why that header will do what you want.
I've been trying to get my head around the whole issue of browser history Vs caching and RFC2616 13.13
Does this section of the RFC mean that if a user goes "Back" in the browser, for example, it should always display the page from it's local storage, ignoring any cache directives, unless the user has configured it otherwise?
So browsers that reload the page when navigating the history, even if caching directives are instructing it do so, are not complying with the specification? And the spec is saying this is bad because "this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to."
Also, even though a directive may instruct the broswer not to cache, e.g. using Cache-Control: no-store, it can/should store it in it's history cache?
From what I've read, it seems that most browsers violate the standard, apart from Opera. Is this because the security concerns around the re-display of pages with sensitive data from history are seen as more important than the issue the standard talks about?
I'd be grateful if anyone is able shed some light/clarification on this area, thanks.
History and cache are completely separate. We're trying to clarify this in httpbis; see https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#history.lists
I am trying to rely upon the browser cache to hold
JSON data returned from AJAX calls in jQuery.
Normal browser activity relies upon the browser cache all the time.
Example: jpg and gif images are not refetched on a page reload.
But when I try using jQuery getJSON ajax calls, I cannot seem to avoid fetching the data from the server.
My returned headers look like this (confirmed with firebug):
Transfer-Encoding: chunked
Date: Wed, 05 Aug 2009 02:55:39 GMT
Content-Type: text/plain; charset=ISO-8859-1
Expires: Wed, 05 Aug 2009 03:55:39 GMT
Cache-Control: max-age=3600
Yet an immediate refresh of the page causes identical requests to hit the server.
I've seen several postings about avoiding caching behavior, which isn't what I need.
I've seen several postings about utilizing caching, but those all seem to rely
upon saving data in the DOM. I want something that behaves just like cached images do during a page reload.
Cant the browser just fetch it from it's own cache?
--x--x--x--x UPDATE --x--x--x--
Much to my disappointment, several respectable folks agree that this isn't just possible.
Some even argue that it shouldn't be (which still baffles me).
Stubburn to a fault, I tried the following:
I set the Etag header on all outgoing pages I want to be cached
(I pick a few choice URL arguments that represent the data I'm requesting and just use that for the Etag value)
At the beginning of the next request, I simply check if the 'If-None-Match' header is in the request. If so, then the browser isn't caching the request like I wanted, so I sent a 304 Not Modified response.
Testing shows that Firefox won't cache my request
(but I can still avoid the 'fetch the expensive data' part of my cgi),
while IE6 will actually cache it (and wont even attempt fetching back from the server).
It's not a pretty answer, but it's working for me for now
(those pesty full-page refreshes of graph data wont be so slow or expensive now).
(What? I'm running IE6! OMG! Oh look a squirrel!)
Ajax caching is possible and predictable (at least in IE and Firefox).
This blog post discusses Ajax caching and has a demo web page:
http://blog.httpwatch.com/2009/08/07/ajax-caching-two-important-facts/
There's also a follow up by Steve Souders on the F5 issue:
http://stevesouders.com/tests/ajax_caching.php
The short answer is no. Unfortunately, browsers do not reliably cache AJAX requests in the same way that they do "normal" pages. (Although the data may in fact be cached, the browser often doesn't use the cache when handling AJAX requests the way you would expect.) This should change in the future, but for now you have to work around it.
You may want to check your resources using the Resource Expert Droid, to make sure they’re doing what you intend. You should also run a network trace to double-check the request and response headers, using something like Wireshark, in case Firebug isn’t telling the full story.
It’s possible that jQuery is including some request headers in a way that the browser decides should bypass the cache. Have you tried a plain XMLHTTPRequest without a framework?
While not the "browser cache" what about session state or some other form of client side saving. You will still have to look into an if modified since situation as mentioned in your comment.
The browser won't natively know if the data has been changed or not since json did retrieve dynamically and what is in the cache is static. I think?
Found a relevant link here after author claimed ajax browser caches are indeed reliable.
claim found here: http://davidwalsh.name/cache-ajax
linked to here: http://ajaxref.com/ch6/builtincache.html
Is it possible to clear all site cache? I would like to do this when the user logs out or the session expires instead of instructing the browser not to cache on each request.
As far as I know, there is no way to instruct the browser to clear all the pages it has cached for your site. The only control that you, as a website author, have over caching of a page occurs when the browser tries to access that page. You can specify that cached versions of your pages should expire at a certain time using the Expires header, but even then the browser won't actually clear the page from its cache at that time.
i certainly hope not - that would give the web site destructive powers over the client machine!
If security is your main concern here, why not use HTTPS? Browsers don't cache content received via HTTPS (or cache it only in memory).
One tricky way to mimic this would be to include the session-id as a parameter when referencing any static piece of content on the site. When the user establishes the session, the browser will recognize all the pieces of content as new due to the inclusion of this parameter. For the duration of the session the browser will used the static content in its cache. After the user logs out and logs back in again, the session-id parameter for the static contents will be different, so the browser will recognize this is as completely new content and will download everything again.
That being said... this is a hack and I wouldn't recommend pursuing it.. For what reason do you want the user's cache to be cleared after their session expires? There's probably a better solution that can fit your situation as opposed to what you are currently asking for.
If you are talking about asp.net cache objects, you can use this:
For Each elem As DictionaryEntry In Cache
Cache.Remove(elem.Key)
Next
to remove items from the cache, but that may not be the full-extent of what you are trying to accomplish.