This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html Multipage: http://www.whatwg.org/C#downloading-or-updating-an-application-cache Complete: http://www.whatwg.org/c#downloading-or-updating-an-application-cache Comment: There is no direction in the spec as to how compressed resources should be treated. If cached resources are served compressed, they should be stored compressed locally to reduce the size of the cache. Posted from: 78.33.9.2 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
My specific example is http://www.offlinebible.com/offline.html. After downloading all resources (about 10Mb over the wire) the Application Cache ends up being around 32Mb. I think this is because while I'm serving the resources GZipped, this preference isn't preserved in the cache. There may be a worthwhile debate about whether certain MIME types should automatically be compressed transparently by the browser implementation of the AppCache interface. Also, any decompression could either be done before the resource is "served" to the browser, or the resource could be "served" to the browser GZipped, as the original resource was (presumably using the browser network stack to decompress rather than duplicating this functionality behind the appcache interface).
This should be completely transparent to the user and author, although I agree that it might affect how much of the quota is used. Not sure exactly what to put in the spec about this.
In particular, consider the following cases: - an appcache pointing to a very small resource (a few bytes). - an appcache pointing to a resource that's just 10GB of 0x00 bytes. - an appcache pointing to a resource that's served compressed to a very small size, but would decompress to 10GB of 0x00 bytes. - an appcache pointing to a resource that's 10GB of incompressible noise. Assume 10GB is far above the allowed default quota. Which should trigger a message to the user, and which should not? It's not just an implementation detail, because regardless of what the precise quota is, some will trigger a warning (or failure) and some won't. I'm thinking that we should probably suggest that quotas are based on uncompressed sizes, not compressed sizes. That way, a slight change to the compressibility of a file won't affect whether it fits or not, and it won't matter if the browser is doing its own compression or not. Any opinions?
Checked in as WHATWG revision r8241. Check-in comment: Suggest that quotas be based on uncompressed sizes, since the alternatives are more abusable and less predictable for authors and users http://html5.org/tools/web-apps-tracker?from=8240&to=8241