On Mon, 13 Apr 2009, Jim Freeman wrote:

> Here's a very stripped down example that will always fail the 2nd time
> through the loop and send the hello.txt GET to the wrong IP. IP addresses
> are hard coded just to eliminate DNS caching as a contributor to the
> problem. The getpeername() call is set for Windows; I believe the arg type
> differs for Linux? Or you can just delete the getpeername() block and just
> use a net sniffer to see the hello.txt GET going to the wrong IP.

Thanks.

I can repeat these sympthoms. The fix is not entirely obvious to me right now,
but I'm strongly leaning towards simply claiming that libcurl doesn't support
this.

The things is that when you ask for CURLOPT_CONNECT_ONLY libcurl only connects
and does nothing more. It pauses there and you extract the socket and you move
on doing something wit the socket that libcurl has no idea about.

That connection cannot be re-use by libcurl of course. But further, all of a
sudden you call curl_easy_reset() on this handle. What do you expect libcurl
to do with that socket at that point? When we added this feature I think we
all pretty much assumed that curl_easy_cleanup() is more or less the only sane
way out of that situation.

I figure one option we have is to detect "dangling" connect-only connections
in curl_easy_reset() and forcible close them.

An alternative approach would be to mark the connect-only connection as "do
not re-use" but there are two problems with this:

  1 - the current "do not re-use" code also implies that the connection is
      closed after use - that is before curl_easy_perform() returns! Thus it
      would need to be better separated

  2 - doing it this way, there's no way for libcurl to ever close the
      connection since it is then never quite complete or done as far as
      libcurl knows. We'd have to introduce a close function as well.

-- 
  / daniel.haxx.se