- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Sat, 3 Nov 2012 09:41:10 +0000
- To: Michael Nordman <michaeln@google.com>
- Cc: Andrew Betts <andrew.betts@ft.com>, "public-fixing-appcache@w3.org" <public-fixing-appcache@w3.org>, Chris Wilson <cwilso@google.com>
On 2 November 2012 20:41, Michael Nordman <michaeln@google.com> wrote: > In some internal discussions about the > 'prefer-online' setting, we were seeking a means of being able to load a > page over the network that could immediately load resources out of an > existing application cache. What does this achieve that can't be done with the HTTP cache? (must-revalidate on page, far-future cache on resources) > The way things currently are, prior to just > hitting the appcache, the manifest file of that existing cache has to be > validated which generally requires a server roundtrip. We were seeking to > eliminate that round trip and thought that more explicit versioning could > help... > > <html manifest="file" manifestVersion="2"> This only works if your page is "prefer-online", otherwise the html page containing the new version number won't be seen as the browser will fetch the previous version of the page from the appcache. The browser will only see the updated version number when the browser updates the appcache (due to a change in the manifest file), meaning the thing signalling an update is available is only seen when an update is made. If you're only targeting the "prefer-offline" case, you could eliminate the manifest http request by far-future caching it & changing it's url when there's a change (essentially moving manifestVersion into the manifest url), as you'd do with other page assets (css/js/img). The problem with manifestVesion and far-future caching the manifest is it's too easy to end up with a strongly cached page that can only be updated by a similarly strongly cached manifest, and vice versa. This locks the user into a particular version of the site.
Received on Saturday, 3 November 2012 09:41:36 UTC