On Mon, 9 Jun 2014, Ray Satiro wrote:

> - res = Curl_done(&data->easy_conn, CURLE_OK, FALSE);
> + res = Curl_done(&data->easy_conn, data->result, FALSE);

Ah yes, that's indeed a suitable change. Thanks!

> After that change the progress callback is not called a final time after
> CURLE_ABORTED_BY_CALLBACK.

For any error really, not only CURLE_ABORTED_BY_CALLBACK.

But it relies on the protocol handler's done function to handle it. I would
like to add a little extra precaution:

--- a/lib/url.c
+++ b/lib/url.c
@@ -5806,11 +5806,11 @@ CURLcode Curl_done(struct connectdata **connp,

    /* this calls the protocol-specific function pointer previously set */
    if(conn->handler->done)
      result = conn->handler->done(conn, status, premature);
    else
- result = CURLE_OK;
+ result = status;

    if(Curl_pgrsDone(conn) && !result)
      result = CURLE_ABORTED_BY_CALLBACK;

    /* if the transfer was completed in a paused state there can be buffered

... for the case where there is no done function for the protocol.

> A side effect of that is in Curl_done() premature will be true so
> Curl_disconnect() will be called and the connection will not be reused (good
> or bad, I guess).

Well, that's up to each protocol handler to handle and that's exactly the way
it should be. For HTTP we really cannot re-use a connection that we "abandon"
somewhere in the middle so it is the correct action.

> I wonder though what happens to the programmer's code if the progress
> callback is no longer called a final time when CURLE_ABORTED_BY_CALLBACK.
> Even if you want to prevent it in this case what if now or in the future you
> have some other callback (ie not
> CURLOPT_PROGRESSFUNCTION/CURLOPT_XFERINFOFUNCTION) that can return
> CURLE_ABORTED_BY_CALLBACK, should the progress function be called a final
> time in that case? Is anyone already relying on a final call to the progress
> function, to get the final counts or something even if fail? I don't know.

This behavior was never guaranteed (and you can easily produce scenarios where
it doesn't happen) so applications have not been able to rely on this
completely. Not saying it can't confuse anyone, just saying that it is not a
documented and guaranteed API functionality.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html