curl-library
RE: Problem with content-length and content-encoding: gzip
Date: Wed, 25 Jun 2003 08:58:43 +0200
Hi Daniel, hi all,
> 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.
I agree with you, but the problem is the streaming sequence. The servers transport layer gets a result from the application handler containing a complete xml document. The content-length is set to the size of the result. Now the header is written uncompressed and the whole data area is sent to the client via a gzip stream.
Unfortunately there is no way to get the size of the compressed data before the complete resulting data is streamed to the client, at least not without causing performance troubles by compressing the whole data in memory first.
> I'm not really sure how to work this out. Any suggestions anyone?
Why not using the resulting decompressed number of bytes provided by zlib to check against the provided content-length (if content-encoding = gzip) of the header?
Best regards,
Erik
-------------------------------------------------------
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
Received on 2003-06-25