Hi All,

I've been using the libcurl library in my open source project called
FTD4Linux for a while with much pleasure. Now I have several
users complaining that my project doesn't work anymore when
they have libcurl 7.12.3 or 7.13.0 installed.

My project communicates with an Apache 2.0.50 HTTP server
(with PHP 4.3.8 and ZLib 1.1.4 installed) which sends responses
in an gzip'ed stream. This has worked perfectly with all versions
of libcurl prior to 7.12.3.

I've tried to find out the cause of this problem by checking out
the CVS repository of libcurl and found out that the contents of
lib/content_encoding.c had a big change between 7.12.2 and 7.12.3.

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.

Because of several authentication headers which need to be send
to the HTTP server to receive an valid reply I can't publicly post
the address+headers of an url which shows the problem. If someone
wants to investigate this problem I can send the exact url + headers
to an private e-mailaddress if necessary.

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.

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

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.

Thanks in advance,

Erik van Pienbroek
Received on 2005-02-12