views:

270

answers:

2

I had good luck with cached offline apps until I tried including data from JSONP endpoints. Here's a tiny example, which loads a single movie from the new Netflix widget API:

<!DOCTYPE html>
<html manifest="main.manifest">
   <head>
      <title>Testing!</title>
   </head>
   <body>
   <p>Attempting to recover a title from Netflix now...</p>
   <script type="text/javascript">
   function ping(r) { alert('API reply: ' + r.catalog_title.title.regular); }
   var cb = new Date().getTime();
   var s = document.createElement('SCRIPT');
   s.src = 'http://movi.es/7Soq?v=2.0&amp;output=json&amp;expand=widget&amp;callback=ping&amp;cacheBuster=' + cb;
   alert('SCRIPT src: ' + s.src);
   s.type = 'text/javascript';
   document.getElementsByTagName('BODY')[0].appendChild(s);
   </script>
</body>
</html>

... and here's the contents of my manifest, main.manifest, which contains no files and is only there so my browser knows to cache the calling HTML file.

CACHE MANIFEST

Yes, I've confirmed that my server is sending the manifest down with the correct content type, text/cache-manifest.

The app works fine--meaning both alerts show--the first time I run it, but subsequent runs, even with the attempt at cache-busting in line 10, seem to be attempting to load the script from cache no matter what the query string is. I see the alert showing the script source, but the callback never fires.

If I remove the manifest link from line 2 and reset my browser--being Safari and the iPhone Simulator--to clear cache, it works every time. I've also tried alerting the number of SCRIPT tags in the page, and it's definitely seeing both the existing and dynamically-created tag in all cases.

A: 

Aha, found it in the spec, of all the crazy places:

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#concept-appcache-onlinewhitelist-wildcard

I needed to add http://movi.es/ to the NETWORK: section of my manifest. Complete file now looks like this:

CACHE MANIFEST

NETWORK:
http://movi.es/

... and seems to hit the network every time.

Kent Brewster
A: 

LIES!

Or, at least, this doesn't seem to work when the endpoint is an SSL URL. Very frustrating.

Tom