Am I thick, or is the real solution to use "Content-encoding: deflate" when the data you're sending is a "deflate" stream, instead of claiming "Content-encoding: gzip" and crossing your fingers?<p>Honestly, that's like changing the extension of a .rar to .zip and asking why Windows Explorer can't open it but gnome-open can.
That's probably because you don't gain anything from gzipping images, right? From memory you might just increase the file size by gzipping, and you'll definitely increase processing work.
A tempest in a teapot.<p>1. A modern graphic file is already maximally compressed.<p>2. Given (1) above, an effort to compress the file further can only make it bigger (one of the paradoxes of misapplied compression).<p>3. So the decision to reject gzipped graphics is wise -- it educates inexperienced programmers in a subtle point about compression technology, more or less by force.<p>The above is true -- take a file composed of supposedly random numbers (or byte values). A good measure of the file's randomness is the inability of a well-written compression algorithm to make it smaller.<p>By contrast, a measure of the redundancy (of exploitable content repetitions or patterns) in a file is the degree to which it <i>can</i> be compressed, the ratio of its compressed versus uncompressed size. In my experience, political speeches tend to be very compressible.
it is pretty clear in google's message: jpeg and pngs images are already compressed (the last step of the compression is similar to a gzip compression in many ways). Putting a jpeg in a zip file is similar to put a zip file in a gzip file. It is usually increasing the space, and it's using some cpu time to inflate / deflate. Whether it is google role or mozilla to teach you that you shouldn't do that is debatable. But I can see why they wouldn't want to develop a feature that's useless and costly. It would be like developping an engine for a car that uses more gas for your car to go slower...
A 899kb JPEG image (100% quality) compressed at best compression will take file size down to 878kb (but who leaves a JPEG at 100% quality?). While compressing a PNG will yield a file of identical size most times, if not larger.<p>I built my own archive format years ago, using bzip2 for game programming. When you compress an already compressed file the result is almost always larger, or at smallest is the same size. On top of having to be decompressed twice on the client side, this is a total waste of server resources.
If I remember the complaints about IE6 correctly, one of them was that IE6 oversteps standards and best practices, rewarding poor coding that wouldn't fly in standards-compliant browsers. If I'm correct on that, this seems more like a "feature" than an actual feature; that is, something you can get away with even though you shouldn't.
If anyone could enlighten me as to why this is I would really appreciate it<p>EDIT: My question was in reference to the latter part of the final conclusion, Chrome sends:<p>Accept:<i>/</i>
Accept-Encoding:gzip,deflate,sdch<p>But doesn't actually support it.
Thanks to hobbit_longon for help pointing out the error in the final point.