I think we just need to adopt this code: http://hg.mozilla.org/mozilla-central/annotate/24eb4aead1ba/netwerk/cache/nsCacheEntryDescriptor.cpp#l348

[ No longer blocks enabling cache2, expected to be fixed after cache2 is on ]

Low priority IMO. I suspect most of the bulk of cached data (images, video, and lots of server-compressed HTML/JS/CSS/etc) is already compressed. This would only fix the cases where servers are too lazy to compress. We have a lot of other cache features on our backlog, and this is probably a small perf win. Also it turned out to take a long time to get right in cache v1 (and we never got it completely right).

It has been decided to not implement this feature. Based on the experience from the past, this is not that simple as it seems to be and bring more problems then good.

(In reply to Honza Bambas (:mayhemer) from comment #3) > It has been decided to not implement this feature. Based on the experience > from the past, this is not that simple as it seems to be and bring more > problems then good. Why? I'm not sure but I guess the cache2's initial version comes with the recognition of the compressed data, then we can drop the compression feature for cache1 (and a pref for forced to enable for v1) and the avoid to bug 715198.

Michal, you had a decent list of arguments why to not fix this, can you please list them here?

Most of the content comes already compressed these days, so there is very little benefit compared to added complexity to the code. My current cache contains 25963 files and only 141 of them are uncompressed html or js. Most filesystems use 4kB blocks so if the cache file is smaller than 4kB then compression has no effect. Entries with size 4-6kB would be probably compressed to a single 4kB block but entries between 6-8k might not. The compression will be efficient for entries larger than 8kB, but I have only 80 such entries in my cache. There are also other issues like that compression makes entries non-seekable.