5 ms·
The feature supported in IE6, but not Chrome
- thomseddon 14y agoIf 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 14y agoIs 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?
- nodata 14y ago(I think he asked to boost the comment ranking for his submission.)
- thomseddon 14y agoI 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?
- hobbit_longon 14y agoI'm not misunderstanding anything. Your very last point contains: "We still don’t quite understand why nobody sends gzip’ed images"
- thomseddon 14y agoQuite right, I have corrected that part of the conclusion, my question referred to the latter part, which I paraphrased above.
- hobbit_longon 14y agoYeah I was right, bitch.
- markhemmings 14y agoGood question. Why doesn't chrome decompress it when their header suggests they will? Yes it's unneeded and discouraged, but if developers do send gzipped content such as images (which as we all (including the blogger) know, they definitely shouldn't!) surely chrome should just go ahead and decompress it as normal?
- haldean 14y agoWhen 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 14y agoWho said anything about encryption?
- deleted 14y ago[deleted]
- campnic 14y agoTake a moment and compare your response to the other responses here. The other two (at the time of this writing) of them are useful to help someone understand something. The author wrote up his thoughts as a blog post and took the time to submit it looking for help understanding an issue. You were unnecessarily rude and condescending in your response. I'm only bringing this up because your account is new. If you're going to take the time to create an account to reply to a post, why would you create an account just to leave this comment?
- hobbit_longon 14y agoThe OP is demonstrably an idiot. He calls himself "Developer, CEO of The Student Cloud", and yet he apparently has no clue whatsoever about the most basic compression algorithms. Zipping compressed images is something that my mother does.
- ruffmuff 14y agoActually, I think the idiot in the room here is you. Read his response again. The author is asking why, if Chrome does not support gzipped images, it sends "Accept:/ Accept-Encoding:gzip,deflate,sdch" (in other words it states that it will accept any Gzipped content). This is the question no one in this thread is actually answering, instead choosing to nitpick on why the author tried to do something. Also, calling someone an idiot because they lack understanding of a certain field in computer science? Really? Maybe you should lighten up.
- nodata 14y agoIt says on that page why: gzipping un gzippable things either provides no benefit or makes them bigger.
- mmahemoff 14y agoCompressing an already-compressed file can make it bigger due to metainfo and the fact the gzip algorithm isn't optimised as well for images as say, jpeg. Furthermore, it's an unnecessary performance overhead on both server and browser (even regular compression is sometimes undesirable for this reason). I guess the browsers figure it's not worth building in support for a feature that's rarely used and creates a sub-optimal UX.
- andreasvc 14y agoIt's not a matter of optimization. Compression removes redundancy. A compressed file will have very little redundancy, so compressing it again is largely a waste of CPU cycles. This is supported by mathematical principles (cf. information theory).
- colanderman 14y ago> Compressing an already-compressed file can make it bigger due to metainfo That's not why, that's just a reason why doing so is silly. > the gzip algorithm isn't optimised as well for images as say, jpeg. gzip is used in PNG. Read the article; the reason is because he wasn't sending gzip data, just deflate data.
- fschwehn 14y ago@2: well, they just gave you some good reasons not to compress files that already are. they want to save resources. so why don't they unzip compressed files that should not be compressed, though they obviously know how to do it? because nobody would care if they did it!
- rejment 14y agoIt actually DOES support the gzip content encoding for images. I just tested in Chrome 21.
- thomseddon 14y agoDoes it? http://news.ycombinator.com/item?id=4422015 http://news.ycombinator.com/item?id=4422015
- aidos 14y agoThat'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 14y agoI think you're forgetting that when you put a compressed file in another compressed file it makes it a surprise.
- 1SaltwaterC 14y agoKinda like flying a plane inside another plane.
- hobbit_longon 14y agogzipping web content isn't optimisation 101, that's optimisation 102. Optimisation 101 is profiling.
- d--b 14y agoit 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...
- rejment 14y agoNot true. If you specify the Content-Encoding headers, Chrome and Firefox decode and display the images properly.
- samuellb 14y agoDoesn't this mean that IE is doing content-type sniffing?
- rejment 14y agoYes it does. It always has done.
- davecardwell 14y agoYes. You can explicitly turn off this behaviour by sending a “X-Content-Type-Options: nosniff” header for IE8+. http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non-standard_response_headers http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Comm...
- thomseddon 14y agohttp://www.thestudentcloud.co.uk/hn/test.php http://www.thestudentcloud.co.uk/hn/test.php doesn't work for me in Chrome 21, but does in Opera 11? Source: <?php header('Content-Encoding: gzip'); header('Content-Type: image/jpeg'); $fin = fopen('test.jpg', "rb"); $fout = fopen('php://output', "w"); $gzipFilter = stream_filter_append($fout, 'zlib.deflate', STREAM_FILTER_WRITE, array('level' => 6, 'window' => 15, 'memory' => 9)); stream_copy_to_stream($fin, $fout); stream_filter_remove($gzipFilter); fclose($fin); fclose($fout);
- pilif 14y agoContent-Encoding: gzip implies a gz header. zlib.deflate just deflates and emits headerless data. Because creating a valid header requires the length of the content to be known, there's no stream filter in PHP to create a gz header. To see Chrome decode your test image, use gzencode() or set Content-Encoding to deflate.
- dotomaz 14y agoDid you send the response header "Content-Encoding:gzip" when serving the image?
- rejment 14y agoHe clearly did not, because if he did he would have noticed that it works. That IE tries to decode anyway is a bug.
- DrJokepu 14y agoAs 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.
- thomseddon 14y agoYeah: http://news.ycombinator.com/item?id=4422015 http://news.ycombinator.com/item?id=4422015
- deleted 14y ago[deleted]
- jcromartie 14y agoFirst: Gzip'ing images is worse than leaving them alone. Don't do it. Second: Chrome always handles gzip with the correct headers.
- colanderman 14y agoAm 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 14y agoYou 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.
- keymone 14y agoam i surprised that absolutely wrong on all levels article contains code examples in PHP? no.
- freehunter 14y agoIf 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.
- lutusp 14y agoA 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.
- trebor 14y agoA 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.