21319 2013-03-18 11:34:35 +0000 appcache: How compression should affect quotas 2013-10-23 22:15:38 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#downloading-or-updating-an-application-cache P3 normal 2014 Q4 1 contributor ian ian mike wintersnight contributor oldest_to_newest 84557 0 contributor 2013-03-18 11:34:35 +0000 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 84558 1 wintersnight 2013-03-18 11:42:05 +0000 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). 85305 2 ian 2013-04-01 19:24:15 +0000 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. 86165 3 ian 2013-04-14 07:03:46 +0000 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? 95267 4 contributor 2013-10-23 22:15:38 +0000 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