Y’know, browsers already have several built-in mechanisms for transparent caching without having to rely on Web Storage. I'd strongly recommend taking a look at them before implementing a jQuery plugin.

The only problem is that HTTP-based caching requires sane server URLs, and the Rails code here indicates a lack of understanding of how to build a cache-friendly URL structure.

I'm also a little fazed by the fact that the 'isCacheValid' key not only checks the validity of the cache, but also sets a cache key at the same time.

I'm one of the guys behind this plugin. In our case built-in browsers cache mechanisms were a no go because we needed to have a programmatic control over our cache. Our app is heavily powered by realtime notifications from the server, and we needed a way to invalidate the cache when some events occurs.

About 'isCacheValid' setting the cache key, you're right, it should have been done in the success callback. The gist is going to be updated soon with your feedback.

Couldn't you use just an extra query string parameter when you want to force a refresh? Like, ?v=12312312353. It's a little hackish I'll grant you, but so is caching HTTP in LocalStorage.

This won't actually cause anything to be evicted from the cache. It just adds a new cache entry with a new key. This is poor resource management, and removes some of the appeal of going out of your way to reuse the browser's cache mechanism.

Sure, but the HTTP cache is managed by the browser. Unless you are pulling down mammoth amounts of data, cache management is unlikely to be a concern for you.

Browsers cache many things each time you go to a website - all the html and assets (js/css/images) will be potentially cached (depending on headers). Often you will not go to that website again. They are optimised for this.

This is better.

Are you referring to using Conditional Get Request for HTTP caching? If so I still think you need to store the results somewhere, after you get the 304 Not Modified response back jQuery will return the blank body of response to the success method. Am I missing something?

I recently ran into something like this where I wanted to cache a JSON (maybe it was JSONP), but couldn't find a solution to store the cached JSON somewhere that works for IE.

If the cache headers are properly configured and you request a page that's cached, the browser will simply serve the page from the cache. It is transparent to the user; it looks just like a normal page request, except the data doesn't actually travel over the wire.

> The only problem is that HTTP-based caching requires sane server URLs

This works great insofar as you aren't bound by PCI requirements; per PCI, you cannot transmit potentially sensitive data in a GET request, and so basically every request must be a POST. Furthermore, implementing CSRF via GET is a non-starter -- that's not even an option.

Hi, Author of locache.js (http://locachejs.org/) here.

I think there is a good use case for something like this in certain situations, but using the browser cache for Ajax requests is generally a better idea.

I wrote locache as a more general client-side cache mechanism for all sorts of objects rather than just caching requests. I was caching lots of backbone models and user actions - it generally worked quite well. I also actually used it quite a bit for caching third party API's that I had no control over (more specifically I was working on a mashup using three different API's and often fetching the same content). When being lazy I tried once to cache my own API and regretted it after as its basically a poor mans browser cache.

Your going to run into a bunch of issues with localStorage if you have not already - specifically to do with memory limits, the blocking API and some strange support on mobile browsers. You may find some useful things in my code, or you may want to drop me a line to discuss it further.

There's no reason AJAX calls can't get cached the normal way. Just set appropriate headers on the response and the browser will cache it for as long as you want.

I'm completely aware that in most cases, the browser should do the job.

Like I said before, we wanted to have a programmatic access to our cache. It let us read what is cached, update it or destroy it when some events occurs.