RE: Connection being reused following a cancellation (HTTP)
Date: Sat, 1 Oct 2011 22:42:57 -0700
> I'm running this on Linux using my current git repo, but I fail to repeat it.
> I always see the third request use a fresh connection after it was aborted by
> a callback in the second request...
Confirming behavior is different using Oct 2 snapshot, the call to multistate(easy, CURLM_STATE_COMPLETED); on line 1661 right after easy->result is set to CURLE_ABORTED_BY_CALLBACK was added. Request doesn't go out anymore which looks promising but from the trace I don't fully understand why the last request gets a brand new connection and there is never a statement about connection #0 being closed, in fact there is no statement about connection #0 at all after request 2 is aborted. When handle #2 is removed from multi Curl_done is called but returns almost immediately on line 5176 (if(conn->bits.done) is true likely because it is the same connection which was used for handle #1). As both handle #2 and #3 are cancelled during first progress callback I'd expect the behavior to be the same. Either both times the connection is closed or both times reused. Also I'd expect connection #0 to be at least closed during curl_multi_cleanup() but there is no statement about it in the trace. Perhaps the trace doesn't te
ll the whole story but looks inconsistent and thus suspicious.
0000: lotsa data
== Info: Connection #0 to host www.amazon.com left intact <-- END OF FIRST SUCCESSFUL LOAD
== Info: Re-using existing connection! (#0) with host www.amazon.com <-- SECOND REQUEST REUSES CONN, GOOD
== Info: Connected to www.amazon.com (188.8.131.52) port 80 (#0)
== Info: Callback aborted <-- ABORTED AND NOTHING GOES OUT, GOOD AGAIN BUT WHAT HAPPENED TO CONN #0 HERE?
== Info: About to connect() to www.amazon.com port 80 (#1) <-- NEW CONNECTION, WHY?
== Info: Trying 184.108.40.206... == Info: Callback aborted
== Info: Closing connection #1 <-- CLOSING #1, WHY #0 WAS NOT CLOSED ADTER 2ND REQUEST?
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-10-02