So I've just fixed deflate version and in my tests it works perfectly ... so perfectly that I choosed to use DEFLATE as first generator option, instead of gzip.
It seems that gzip causes too many problems with some version of Internet Explorer while I have
gzip VS DEFLATE ?
Well, it seems that DEFLATE performs a compression quite faster than gzip but packed.it goal is to forget runtime compression ... so this point doesn't matter while decompression speed should be a better plus, again, for DEFLATE.
At the same time DEFLATE seems
The result code should be more slim using gzip but We are talking about 2%, max 3%, that's not a problem with both big and medium / regular compressed sources.
So what's new ?
The news is that now packed.it generators (PHP 4 or 5, C# Mono or .NET, Python PSP or WSGI) works correctly with deflate version (now compressed respecting RFC 1951) and choose them as first option.
You can obviously change priority by yourself, if You think gzip is better, however I'll mantain this choice if anyone will tell me that DEFLATE has same or more problems that gzip.
"gzip" is the gzip format, and "deflate" is the zlib format. They should probably have called the second one "zlib" instead to avoid confusion with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 correctly points to the zlib specification in RFC 1950 for the "deflate" transfer encoding, there have been reports of servers and browsers that incorrectly produce or expect raw deflate data per the deflate specficiation in RFC 1951, most notably Microsoft. So even though the "deflate" transfer encoding using the zlib format would be the more efficient approach (and in fact exactly what the zlib format was designed for), using the "gzip" transfer encoding is probably more reliable due to an unfortunate choice of name on the part of the HTTP 1.1 authors.
Have a nice optimization with packed.it ! (and please let me know if deflate will cause problems that gzip didn't cause)