
The feature supported in IE6, but not Chrome - thomseddon
http://blog.thomseddon.co.uk/gzip-support-in-chrome/
======
colanderman
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?

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.

~~~
thomseddon
You are quite right, and it would be the correct way to do it with a stream
filter, so thanks.

Personally I had never thought to look what the deflate indicated and figured
it was similar to sdch, now I know.

------
rejment
Not true. If you specify the Content-Encoding headers, Chrome and Firefox
decode and display the images properly.

~~~
samuellb
Doesn't this mean that IE is doing content-type sniffing?

~~~
rejment
Yes it does. It always has done.

------
jcromartie
First: Gzip'ing images is _worse_ than leaving them alone. Don't do it.

Second: Chrome always handles gzip with the correct headers.

------
dotomaz
Did you send the response header "Content-Encoding:gzip" when serving the
image?

~~~
rejment
He clearly did not, because if he did he would have noticed that it works.
That IE tries to decode anyway is a bug.

~~~
DrJokepu
As far as I know, the HTTP standard doesn't require browsers to decode content
with a decoding mechanism if and only if it has been specified in the Content-
Encoding header. I don't think this is a bug.

------
aidos
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.

~~~
batgaijin
I think you're forgetting that when you put a compressed file in another
compressed file it makes it a surprise.

~~~
1SaltwaterC
Kinda like flying a plane inside another plane.

------
lutusp
A tempest in a teapot.

1\. A modern graphic file is already maximally compressed.

2\. Given (1) above, an effort to compress the file further can only make it
bigger (one of the paradoxes of misapplied compression).

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.

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.

By contrast, a measure of the redundancy (of exploitable content repetitions
or patterns) in a file is the degree to which it _can_ be compressed, the
ratio of its compressed versus uncompressed size. In my experience, political
speeches tend to be very compressible.

------
d--b
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...

------
trebor
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.

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.

------
freehunter
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.

------
thomseddon
If anyone could enlighten me as to why this is I would really appreciate it

EDIT: My question was in reference to the latter part of the final conclusion,
Chrome sends:

Accept: _/_ Accept-Encoding:gzip,deflate,sdch

But doesn't actually support it. Thanks to hobbit_longon for help pointing out
the error in the final point.

~~~
hobbit_longon
Is this a joke?

You want to know why people don't gzip their images? What benefit do you think
you get from gziping a jpeg or png stream? Why were you trying it in the first
place?

~~~
thomseddon
I think you may have misunderstood the conclusion of the article and so hence
my question: When requesting an image chrome sends:

Accept: _/_

Accept-Encoding:gzip,deflate,sdch

But if you abide by this and send it gzip'ed it fails...why?

~~~
haldean
When the request is sent Chrome doesn't know the content type of the response,
so it can't know that what it's requesting is an already-encrypted file.

~~~
hobbit_longon
Who said anything about encryption?

------
keymone
am i surprised that absolutely wrong on all levels article contains code
examples in PHP?

no.

------
hobbit_longon
gzipping web content isn't optimisation 101, that's optimisation 102.

Optimisation 101 is profiling.

