shinypb / appcachefacts Goto Github PK

It seems like you lost control of the appcachefacts.info domain? It points to spam now.

Working html here: https://web.archive.org/web/20140911203145/http://appcachefacts.info/

https://github.com/shinypb/appcachefacts/blob/master/index.html#L144

Over SSL, all resources in the manifest must respect the same-origin policy.

From my testing today, Safari 6.0.5 and Firefox 23 behave the same as Chrome. That is, they all work fine with resources that are hosted on different domains, even for a HTTPS web site. I'm not sure how far back this change goes, but that means these browsers are now apparently against the specification (although this does put my mind at ease).

As an aside, hitting Refresh in Firefox does not work at all with Application Cache. It is necessary to create a new tab / window.

I did some testing and I didn't see this information anywhere on the web, so if you can please add it to the page for future reference and education of the masses!

First I wanted to know if I could create two seperate appcaches for one website domain.
=> It looks like that is perfectly possible!
This is important, because I have a dutch and french version, the people visiting the dutch version could have the dutch appcache and vice versa.

I hoped for a moment that the 5MB limit would be per appcache file, but it's not. This is probably per domain.

What also was important is that the caching system is case sensitive!
I use an IIS webserver wich is not, and then I made a 'case sensitivity' error => point proven ;-)

And last but not least: If a page is loaded from the appcache and a resource (image) it needs is not in the appcache, the image is not loaded even if your server is online and you are connected to the internet!!

Thank you for your time, please double check my findings and add them to the wonderfull resource!

And I am not saying this in a ironic way. :P

It would be nice if we could also annotate the manifest file, like this: http://timdream.org/site.appcache

AppCache now works with Github pages, I filed an issue a while ago (and got fixed) to have them send the correct MIME.

I test application offline features in chrome ( by now , it's 30 ), and what made me confused is that after change my manifest , event the application cache events go well ( checking, downloading, updateready..), but the resources still not update( after I refresh the page again ). However I have done lots of experiments, and it turn out that it is caused by the cache-control.

For example, if cache-control set to max-age:20, then during this 20sec, if I update my manifest file, the page will reloading all the resources within the list, but all the downloading process just use the browser cache( not offline cache, just browser cache created by cache-control ), which means your resources will not be updated even u update your manifest.

And this problem just happen to Chrome Desktop version, all the mobile version I have tested just work well.

Just wonder if anyone else also had found this issue?

Looks like something might have died :( http://appcachefacts.info/ is totally down for me.

new URL: http://diveintohtml5.info/offline.html

Discovered this fun appcache fact on some recent work. With Firefox if your cache manifest has an HTTP Expires header set to a past time, then the manifest will not download.

This can be a problem if your framework adds these automatically to get round overly aggressive proxies.

For the FACT:

Firefox will always ask the user for permission before caching a site for the first time.

Can you clarify that it is ONLY Firefox that has this issue?

And confirm that for all other browsers the experience is seamless.

Thanks.

dont have the time to add these right now so i'm putting em here for safekeeping

procedure

http://www.slideshare.net/remy.sharp/html5-tutorial-canvas-offfline-sockets slides 46-48

caching and appcache

when you rev the appCache .manifest file, the browser collects all the urls of the assets that need to be updated and see if they need cache validation down at the network layer. The etags/lastmodified/expires headers, etc. are considered, with the browser only fetching what is necessary.

If a file listed in the appCache .manifest file is changed, but the .manifest file itself is not updated or reved, even if there are new caching headers the browser will not refetch.

of course, in order for the files to refetch, the manifest itself still needs to change

I’m quite certain that the Vary header is meaningless in appcache. E.g., if you wanted to serve a different page based on language, you would have to make your site’s URIs vary by language too by using domains or lang=x query strings. If you try to use the Vary header and your application stores server-generated pages where the server outputs different results based on Vary, the user will only see the content as the browser accessed the website the first time.

This is my understanding/assumption, I have not actually tested for real.