Internet Explorer 7 is supposed to support gzip and deflate encoding. Right? Despite the support advertised via the Accept-Encoding header, I noticed it does only support gzip encoding, but not deflate.
Internet Explorer 7 sends an Accept-Encoding header with the value gzip, deflate. But if I return the response deflate encoded,
Content-Encoding: deflate
Internet Explorer 7 chokes in it. I was surprised by this. But if I change the encoding to gzip it is able to process the response. Per an MSDN blog post, IE7 is supposed to support both these encodings.
Hmm. The issue is that, for the sake of speed, I am storing GPS logs deflateed in the database, and would like to serve it as it is to browsers, without having to let my Apache compress it on every request. This works with Safari, Opera, and Firefox, but not Internet Explorer 7. Oh well!
Update
Here is what IE 7 says.
and here is what Firefox 2.0 says.
Mike’s example in the comments disagrees with this. Too packed today to resolve this.
Update
Per Eric’s comment below, IE7 should deal with deflated responses fine. However, it did not, in my case. After spending a weekend on this problem, I sent my logs to Eric, who kindly volunteered to take a look.
{ 13 comments… read them below or add one }
I was able to set up a quick test page for IE7 that returns valid data for deflate. test this link:
http://amundsen.com/examples/deflate/test.ashx
I’m using IIS7, ASP.NET and the System.IO.Compression.DeflateStream class from the .NET library.
Ping me if you have any questions.
Internet Explorer 7 correctly handles DEFLATE’d content, which is used on several major websites.
If you send me a Fiddler log (see http://www.fiddlercap.com for simple steps) I’d love to take a look at it.
How are you performing the deflating? Are you adding or removing any headers in the stream?
For what it is worth, gzipped content is comming out truncated too for me with ie7, not with firefox.
Bartwe– If you send me a Fiddler log (see http://www.fiddlercap.com for simple steps) I’d love to take a look at it.
Did you ever figure out what was going on with this IE7 deflate issue?
Yes, just yesterday.
In my tests, the compression was done using Ruby’s Zlib::Deflate. All browsers except IE were able to handle this correctly.
To get this to work in IE, I had to strip out the first two bytes off the deflated content. Both IE and FF are now able to handle this.
There is some clue here:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=97064
Incidentally, PHP’s gzinflate also required stripping off the same two bytes.
The first two bytes of zlib compressed output are 78 and 9C, and the deflate stream starts from the third byte onwards. FF, Opera and Safari recognize the zflib stream for these magic bytes, but IE chokes on it. Technically IE7 is right since these two bytes are not part of RFC 1951.
Here is a good explanation of these two bytes:
http://www.groupsrv.com/science/about176335.html
Same issue if you deflate with java.util.zip.Deflater. First two bytes must be eaten, and not sent to IE…
I realise that this is a very belated response but better late than never…
The issue here is a Microsoft misinterpretation of RFC 2616 (the IETF document standardising HTTP 1.1). Contrary to the above comment by Subbu Allamaraju, IE is technically incorrect. RFC 2616 states clearly that “Transfer-Encoding: deflate” means that the entity has been compressed according to the zlib format specified by RFC 1950. The zlib format is just a very thin wrapper around the deflate format specified by RFC 1951. The problem is that IE interprets “Transfer-Encoding: deflate” as meaning the raw RFC 1951 format rather than the wrapped RFC 1950 format stipulated by the standard. The confusion might have been avoided if the good people in the IETF had used the token “zlib” instead of “deflate”.
A couple of more points in the interests of correctness. First of all, zlib data will not always have a two byte header consisting of 0×78 and 0×9c. The values will be different if a window size other than 32 KB has been used by the deflater, and there will be four additional header bytes if a custom dictionary has been used by the deflater.
Finally, it’s worth pointing out that although the System.IO.Compression classes in .NET support only the raw deflate format, the 3rd party ICSharpLib.SharpZipLib .NET class library supports both the raw deflate format and wrapped zlib format – it depends on the value of a flag passed to the relevant class constructor. I’m pretty sure the Java implementations are switchable too.
I realize this is even more belated, but in case anyone else is banging their head against this, we’ve found that using a java.util.zip.Deflater instance with nowrap=true results in content that’s usable by IE7 as well as the others (Firefox, Safari, etc).
That is,
d = new jav.util.zip.Deflater(java.util.zip.Deflater.DEFAULT_COMPRESSION, true);
os = new java.util.zip.DeflaterOutputStream(os, d);
Nice Blog. I see you are using Wordpress – You and your readers should make certain that you are running the latest version of Wordpress as previous updates are vulnerable to exploits.Cheers
Christ, IE is horrible. I just wish they’d give up making browsers – but I know their goal is to hurt interoperable website technologies, not make a good browser, so I’m sure they’ll keep it up.