Re: Another bug in lib/content_encoding.c
Date: Sun, 13 Feb 2005 00:12:49 +0100
Dan Fandrich wrote:
>An "incorrect data check" error is to be expected if the gzip data stream
>were truncated so the CRC at the end of the file were missing (at least if
>you're using zlib ver. 1.2.x). This corroborates the error code given
>from curl. All the evidence points to a corrupted gzip data stream.
>The big change in 7.12.13 was to use zlib's 1.2's built-in gzip header/
>trailer parsing routines instead of the ones in content_encoding.c, when
>available. The latter do not validate the gzip CRC so you won't get such an
>error when using them. You can verify this by using the stock 7.12.13
>(or 7.13.0) sources with zlib 1.4, or by subverting the run-time zlib
>version check in content_encoding.c to simulate an older version of
I've just experimented a bit with the PHP scripts my project calls and found
out the problem isn't in libcurl but in PHP. What happens is the following:
First, the PHP script calls the function | ob_start("ob_gzhandler"); to
gzip'ed output and when the output is finished the function
||while (@ob_end_flush()); is called. These 2 instructions cause PHP to
produce invalid gzip'ed data. If the ob_end_flush() function is left out
the output of the webserver is correct gzip'ed data.
Thanks for your help and sorry to have bothered you
with this false bugreport.
Erik van Pienbroek
Received on 2005-02-13