On Sat, Feb 12, 2005 at 03:40:00PM +0100, Erik van Pienbroek wrote:
> I've then tried the following: first I unpacked both the 7.12.2
> and 7.12.3 source tarball's and I copied the file lib/content_encoding.c
> from the 7.12.2 release to the 7.12.3 release and then I
> compiled/installed the 7.12.3 release. After that my project worked
> again as it did before the 7.12.3 release, so the problem lies in
> the changes that occured between the 7.12.2 en 7.12.3 release.
[...]
> I've published some gzip'ed data from that HTTP server to my
> own HTTP server: http://www.ftd4linux.2y.net/curl_dump.gz
> When I try to unpack this file with the command
> 'gunzip curl_dump.gz -c' then the right contents of the
> uncompressed stream are shown. gunzip does bail out
> with the message 'unexpected end of file' but the contents
> of the file are fully decoded at that point. This means to me
> that the data from the HTTP server is valid gzip'ed data.

On the contrary, that tells me that the data from the HTTP server is
*invalid* gzip'ed data. gzip shouldn't be giving you any error message
if the data were indeed valid. Just because you get the expected data out
doesn't mean you have a valid gzip data stream.

> When I try to fetch the data via the curl command line
> program it bails out with the following error :
> curl: (23) Error while processing content unencoding: incorrect data check
> (the program bails out when it's halfway decoding the stream).

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

> I hope that this email gives you enough information to localize and
> solve the problem. Oh BTW, the recent change in the file
> lib/content_encoding.c (fix for the 64kb bug) doesn't solve my problem.

Sounds like you need to fix your web server.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved