On Thu, 27 Aug 2009, Mark Aldred wrote:

> My application uses CURLOPT_READFUNCTION and CURLOPT_WRITEFUNCTION copy the
> data into and out of curl. My callback functions us structures to track how
> much data has been copied to maintain sane pointers as the copy progresses.
> Fairly standard stuff. When curl return an error to our application my code
> resets the pointers used in the data copy and retires the curl request (for
> retryable errors). All this works fine.

Well, that's one way to see it. I'd say it doesn't really "retry" requests.
But it does have some minor ways to detect that a re-used connection dies and
then it needs to have a way to recover from that to make the app not have to
care about it etc.

> Today I encountered a situation where it appears I issued a PUT request to
> curl. Curl got the 100-continue from the host, invoked by copy function to
> get all the data then encountered an error. It seems that curl then retried
> the operation without returning an error to my application

That sounds fishy. In what way did it fail?

> The result is that when curl invoked the copy function in my application for
> the retry, my copy function returned zero because it thought (correctly)
> that all the data had been copied already.

Do you have CURLOPT_SEEKFUNCTION set? Was it then not used?

> Does curl retry requests without returning an error to the application so
> that it can prepare for the retry?

No, not really. I think it looks like you've found an error that it wrongly
retries stuff on.

-- 
  / daniel.haxx.se