Dan Kohn <dan(_at_)dankohn(_dot_)com> wrote:
The main advantage of gzip that I can see is the CRC32 and
Ah, I hadn't realized how much weaker the Adler32 checksum is compared
to CRC32, but I just poked around the web, and it looks like there is
mounting evidence that the difference is significant, especially for
small inputs (less than several kB).
In defense of zlib (not that it's mine to defend--I had nothing to do
with it), I'd like to point out that zlib was designed at the same
time as its first application, PNG, which already provides a CRC32
on the compressed data. The zlib checksum on the uncompressed data
was therefore serving only to detect errors in the deflate/inflate
implementations, not to detect corruption of the PNG stream. The zlib
designers may have expected that to be the typical case: the zlib
checksum would be in addition to a higher-layer checksum.
I now see why Content-MD5 is relevant. If Content-MD5 is present, it
is already plenty strong enough, so it doesn't matter whether there is
another checksum on the same data, or what it is. But if Content-MD5 is
absent, and the transfer-encoding checksum is the only end-to-end check,
then its strength matters.
the ease of piping things through the gzip program.
Yes. I had thought that there was a flip side of that coin, that the
lack of a libgzip was a disadvantage for implementations that want to
avoid the performance cost of a pipe, but I just learned that zlib
supports gzip streams too.
AMC