On Fri, 11 Nov 2005, Michael Wallner wrote:

> This may sound like a rant, but is hopefully the beginning of something
> constructive :)

I like constructive!

> It currently seems impossible to me to squeeze data with standard
> methodology out of libcurl that can be properly serialized/deserialized,
> here's why:

I suspect that your use case is somewhat different that the most, considering
that getting the data is what libcurl is about and your issues are mostly
about getting the raw data and do the things on your own that other people
would say is the actual reason they use libcurl in the first place.

That said, I'm open to improve libcurl to better fid a wider audience.

> - no raw callback (most of the following points could probably be solved
> with that)

You mean one like the debug callback? Or how would it differ from the debug
one?

> - no response bodies for redirects are provided

Nope. I've always considered libcurl to be about transferring data and when
you ask libcurl to follow redirects you still want the data of the final
"page". Redirects or not.

If you don't like that, don't ask libcurl to follow redirects and do the
redirect magic yourself instead and there will be no problems.

Or invent a new option that passes the 30x response bodies to the callback as
well.

> - no real indicator if the data already is from a following response when
> redirected

You can count them and you can check response code. In what way would you like
to be notified about the different responses?

> - compressed data is inflated without updating headers (I can't force
> libcurl not to inflate)

libcurl never "updates" headers, it passes on the ones it got. Yes, you can
indeed force libcurl not to inflate, simply by not asking it to do it.

> - chunked encoded data is decoded without updating headers (I can't force
> libcurl not to decode)

You are the first person ever who've requested this. May I ask what the use
case is for such an odd wish?

How would you like to have that done if you'd get to choose?

> My current way to overcome these issues is to abuse the debug callback as
> kind of a raw callback

How is that abusing? And why is it only a "kind of" raw callback?

> which means that libcurl does many things I do afterwards anyway (or vice
> versa depending on POV).

Yes it seems so. But why do you it on your own when libcurl does it for you?

> I could easily understand if curl did all those things but I don't yet get
> why libcurl is doing it.

Because libcurl is a transfer library that transfers data. In general people
are interested in getting the data out from libcurl with as little extra fuzz
as possible, and that's what libcurl attempts to offer.

My question is rather the opposite: why would you force all that decoding work
to hundreds of applications, when libcurl can do it so easily for them?

But really, my main point with this reply is: please provide your suggestions
on how you would like to address the shortcomings you see. It is a lot easier
to discuss and debate around actual proposals.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html