On Fri, 20 Jun 2003, Erik Rehrmann wrote:

> I'm using libcurl (7.10.5) as the transport layer for xmlrpc-c and trying to
> use the content-encoding feature (curl_easy_setopt(curl, CURLOPT_ENCODING,
> "gzip");).
>
> Unfortuately it seems to me as if the content-length of the server response
> (Marquee XMLRPC - Java) is evaluated although it doesn't contain the
> compressed data size. RFC 2616 does not well describe the content-length
> content if the content is encoded, so I don't know who's wrong, the server
> which sends the response with the "real"-length, or libcurl which evaluates
> the content-length.

I can see why this causes you trouble.

I agree that RFC2616 is not very clear on this point. I do however have my own
opinion in this matter: I'm pretty sure that the server should send a
Content-Length: header that specifies the size of the content that it sends.
The server only sends the compressed number of bytes, and thus it should say
so.

It does not send any more than that and should thus not tell the client how
big the content will become when it decompress it, it is not relevant in the
network context that HTTP works.

> Below you can find a code snippet where the error occurs

That's the exact code snippet that will cause the error code to be returned,
yes. If you remove that check, not only will libcurl fail to detect errors in
other (not related to this) scenarios but it also will fail to properly work
with persistent connections on compressed transfers, as it would be severly
confused about when the data transfer is actually done.

I'm not really sure how to work this out. Any suggestions anyone?

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php