views:

371

answers:

4

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!)

A: 

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?

klabranche
A: 

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.

harpo
Yeah. It is inconsistent at best. Sometimes they do when you're least expecting it.
jason
A: 

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?

Carey
website is not public, so cannot use redbot, but thanks. wireshark shows the same headers than firebug shows. I have not tried XMLHTTPRequest directly (pointer to a how-to for that?)
ericslaw
The classic XMLHTTPRequest reference: http://developer.apple.com/internet/webcontent/xmlhttpreq.htmlIf you're really keen, you can install redbot locally.
Carey
+3  A: 

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

HttpWatchSupport