in Uncategorized

IE7 – Deflate or Not?

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!


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.


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.

Write a Comment



  1. 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:

    Incidentally, PHP’s gzinflate also required stripping off the same two bytes.

  2. Same issue if you deflate with First two bytes must be eaten, and not sent to IE…

  3. 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 0x78 and 0x9c. 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.

  4. I realize this is even more belated, but in case anyone else is banging their head against this, we’ve found that using a instance with nowrap=true results in content that’s usable by IE7 as well as the others (Firefox, Safari, etc).

    That is,

    d = new, true);
    os = new, d);

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

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

  • Related Content by Tag