This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15700 as part of operation convergence. Originally filed: 2012-01-24 22:23:00 +0000 Original reporter: Tobie Langel <tobie.langel@gmail.com> ================================================================================ #0 Tobie Langel 2012-01-24 22:23:11 +0000 -------------------------------------------------------------------------------- Currently, the editor's draft allows preventing content from being cached by using the no-store http header. Often, developers cannot or do not know how to modify http headers to block sensitive parts of a website from being cached (when visited) by AppCache. e.g.: A website containing both public and sensitive HTML pages needs to be made available offline. The sensitive data must not be stored on the device. The website is hosted on a virtual host and HTTP headers cannot be modified. The web developer can prevent such pages from being cached by specifying them directly in the manifest. ================================================================================ #1 Ian 'Hixie' Hickson 2012-01-31 23:24:05 +0000 -------------------------------------------------------------------------------- Why would any pages be cached if they're not listed in the manifest? Also, who on earth is dealing with sensitive data yet can't change caching headers? That's a frightening thought. ================================================================================ #2 Tobie Langel 2012-03-27 14:16:09 +0000 -------------------------------------------------------------------------------- They'd be cached as master entries simply by being visited. ================================================================================
A file is only going to end up cached as a master entry if it's got a manifest="" attribute, no?
I don't really understand the problem here. The only files that are going to get cached are the ones the author opts to have cached, either by setting a manifest="" attribute, or by putting them in the manifest. Even in browsers that don't have manifest support, if you go to a page, it'll get cached unless you have headers set to avoid caching. So if you don't want caching, you need to update headers, that's got nothing to do with appcache. Updating headers for caching is much simpler to do than other things you have to do when dealing with sensitive data, so I don't understand who would have a problem here.
Tobie: Please reopen this bug if you can provide the information needed. Thanks.
The requirement here was to be able to prevent caching the master entry, while caching the sub-resources.
That would be pointless. It would literally mean you got no benefit from appcache whatsoever beyond just normal HTTP caching.