Cache Manifest is Too Hard to Adopt

[paulirish]

Because the cache manifest requires that the main HTML asset is cached, it is difficult for people with existing pages to adopt it. If they wanted to use the cache manifest, they would have to change their site to make the main index.html more permanent, and use JavaScript to update the content on the main page and prompt the user to refresh.

Specific Issues

• Use of the cache manifest mandates a user-implemented refresh-to-update UI.
• It is not possible to use the cache manifest for offline support without also opting in to its aggressive non-blocking behavior when the user agent is online.
• If any resources in the CACHE section return a 404, the entire cache manifest is disabled

Specific Suggestions

• It should be possible to declare that the main HTML resource should only be non-blockingly served from the cache if the user agent is offline. If the user agent is online, a single blocking request would first verify the freshness of the cache using the existing semantics.
  • Action Item: What is the syntax for this?
  • Open question: Can this be added without breaking existing cache manifest parsers?
  • External Contact: W3C
• It should be possible to declare that certain resources are optional. If a resource is optional, a 404 response code for the resource would not invalidate the entire app cache.
  • This would retain the current atomicity of the existing application cache semantics, while allowing optional exceptions.
  • Action item: What is the syntax for this?
  • Open question: Can this be added without breaking existing cache manifest parsers?
  • External Contact: W3C
• There should be browser behavior to prompt the user to reload a page where the cache has updated.
  • External Contact: Browser Vendors

General Open Questions

What is a cache manifest group?

References

http://www.stevesouders.com/blog/2011/10/03/improving-app-cache/
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

[tobie]

Regarding you're last suggestion: "There should be browser behavior to prompt the user to reload a page where the cache has updated" this should be either kept app-specific or triggered by a cancelable event. Long-lived applications (such as Gmail for example) or regular websites using AppCache as an asset preloader have very different needs and expectations.

[sethladd]

I would also add this request: I'd like to be able to signal specifically which resource in my app cache is new.

The current behavior is to fetch each resource in the cache when the manifest is touched/updated. This is unnecessary in most cases, as in most cases only a limited number of resources are actually new.

If I can specify which resources have been updated, this saves bandwidth, server resources, and speeds up the client.

See http://blog.sethladd.com/2010/10/proposal-to-enhance-html5-app-cache.html for one option.

[tobie]

Seth: Isn't this already covered in 17.3 of the application cache download process by using fingerprinted assets with Expires headers set far away in the future?

If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache.

[hotTea]

It would also be nice to be able to tell the browser to delete cache programmatically (for eg. by Javascript). Consider the case when you have a mobile version and full version of the site hosted on the same domain. Both versions uses cache manifest, but will have diff. resources. User wants to switch from mobile version of the site to full version of the site, but since they both are hosted on the same domain, browser will still load resources of mobile version (from the cache manifest of mobile site), even if the server tries to present the full site. If there was a way to delete current cache, then it could have worked.

[sindresorhus]

There is also a need to be able to dynamically mutate the appcache by adding/removing/updating items with Javascript.

The now defunct DataCache spec would have solved some of these issues.

There is an open issue for this on the W3C issue tracker, but it looks like it's not a high priority.

[tobie]

There's a number of security concerns that arise when code which can
be modified when a user isn't logged in runs when a user logs in.

[wycats]

@sindresorhus also, the cache manifest is designed to support atomic sets of assets, which I'm not sure is what people want when they want to add items dynamically.

[sindresorhus]

@tobie I'm not sure I follow. Can you elaborate on what security problems it would cause?

@wycats With the newfound popularity of having almost everything client-side, there is an actual need to be able to cache assets dynamically from the client. If not appcache, then something else. We're currently experimenting with [ab]using localStorage for this. But that is only a workaround until we get something solid.

[tobie]

On a shared computer, user A logs onto example.com, overwrites one of
the existing scripts so it does something evil and logs out. Whenever
user B logs onto example.com on the same computer, he's unknowingly
running in a compromised environment.

[leobalter]

I believe this is solved with ServiceWorkers. Please re-open if necessary