cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Chunked encoding content in callback writefunction?

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Tue, 27 May 2003 23:54:57 +0200 (CEST)

On Tue, 27 May 2003, Cyrill Osterwalder wrote:

> Wow, that's a real fast response, thanks!

;-)

> Yeah, I agree that the normal usage does not require that at all. I'm using
> libcurl for a proxy connection and that's probably not the original idea of
> it. And yes, I know that I can do proxy with other components but I really
> like the curl approach for various reasons ;-)

I come to think of that you can actually already get the data before it gets
"dechunked", by setting a DEBUGFUNCTION.

> I still think that it would be nice to have header and content data
> consistent if you want to. Your advice about removing the transfer encoding
> information from the header sounds good, I'll look into that. There might
> be some issues regarding the content-length which is not known in the HTTP
> header for chunked encoded contents, right?

Yes, but that's no different than what HTTP 1.0 will give you and you already
used that as a work-around.

Besides, you could in fact add your own chunks around the dechunked data
delivered by libcurl! ;-)

> So I would have to calculate the content length before I could reassemble
> the correct header. That would mean that I have to cache all content before
> I can send back a response(?) if I want to include content length in the
> header.

Seems like a bad idea if you wanna download files of considerable sizes...

> Does libcurl cache all contents anyway, even for huge downloads?

Nope. libcurl only uses a normal-style download buffer, it doesn't cache
transfered data. It caches a few other things though, as documented.

> The HTTP 1.0 switch seems to work fine as the fallback workaround.

Try using the DATA_IN in the debugfunction. I think it'll give you what you
want.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Received on 2003-05-27