On Thu, 27 Dec 2007, Dmitriy Sergeyev wrote:

Thanks for the updates!

> By the way, is it necessary to do the following?
> ==========
> do {
> code = curl_multi_perform(multi, &handles);
> } while (CURLM_CALL_MULTI_PERFORM == code);
> ==========

No, I just didn't spot your way of dealing with it so I wrote it that way when
trying to debug things and it ended up in the version I posted back here...

> But in this case curl_easy_pause() can be called when curl_multi_perform
> returns CURLM_CALL_MULTI_PERFORM. Is this forbidden?

No, it should be possible to call curl_easy_pause() in just about all possible
states as far as I can think of right now.

> This one uses "Accept-Encoding: gzip,deflate". For small resources (~20kb)
> it works good, but for large resources (~300kb), which retrieval takes
> several write-callback calls, the resulting resource is corrupted.

Yeah, I can easily reproduce it as well, and I can also see why it happens. In
the code that deals with compressed data, the code loops decompressing and
writing multiple times, so returning 'pause' in the middle there won't work.
It'll just continue and try writing the next block again with this outcome:

#1 - some data vanishes
#2 - you get the callback called again even though the previous one return
      pause, which you easily see in your app with your state checks

This looping technique is making it difficult to make a quick fix for this. It
will take some further thinking and code restructuring. I'll have to let this
problem get some thoughts in the back of my head for a few days before I do
anything further on pausing.

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