Dirk Manske reported a regression. When connecting with the multi
interface, there were situations where libcurl wouldn't store
connect time correctly as it used to (and is documented to) do.

Using his fine sample program we could repeat it, and I wrote up
test case 573 using that code. The problem does not easily show
itself using the local test suite though.

The fix, also as suggested by Dirk, is a bit on the ugly side as
it adds yet another call to Curl_verboseconnect() and setting the
TIMER_CONNECT time.  That situation is subject for some closer
inspection in the future.

The necessary libssh2 functions require libssh2 1.2.5 or later.

Also tweaked comments in certain examples using curl_multi_fdset().

The -O option caused curl to crash on windows and DOS due to the
tool writing out of boundary memory.

Prefixing the FTP quote commands with an asterisk really only
worked for the postquote actions. This is now fixed and test case
227 has been extended to verify.

Matt Wixson found and fixed a bug in the SCP/SFTP area where the
code treated a 0 return code from libssh2 to be the same as
EAGAIN while in reality it isn't. The problem caused a hang in
SFTP transfers from a MessageWay server.

Ben Greear brought a patch that from now on allows all protocols
to specify name and user within the URL, in the same manner HTTP
and FTP have been allowed to in the past - although far from all
of the libcurl supported protocols actually have that feature in
their URL definition spec.

Bob Richmond: There's an annoying situation where libcurl will
read new HTTP response data from a socket, then check if it's a
timeout if one is set. If the last packet received constitutes
the end of the response body, libcurl still treats it as a
timeout condition and reports a message like:

"Operation timed out after 3000 milliseconds with 876 out of 876
bytes received"

It should only a timeout if the timer lapsed and we DIDN'T
receive the end of the response body yet.

Christopher Conroy fixed a problem with RTSP and GET_PARAMETER
reported to us by Massimo Callegari. There's a new test case 572
that verifies this now.

Kenny To filed the bug report #2963679 with patch to fix a
problem he experienced with doing multi interface HTTP POST over
a proxy using PROXYTUNNEL. He found a case where it would connect
fine but bits.tcpconnect was not set correct so libcurl didn't
work properly.

(http://curl.haxx.se/bug/view.cgi?id=2963679)

Akos Pasztory filed debian bug report #572276
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276
mentioning a problem with a resource that returns chunked-encoded
_and_ with a Content-Length and libcurl failed to properly ignore
the latter information.

Hauke Duden provided an example program that made the multi
interface crash.  His example simply used the multi interface and
did first one FTP transfer and after completion it used a second
easy handle and did another FTP transfer on the same FTP server.

This triggered a bug in the "delayed easy handle kill" system
that curl uses: when an FTP connection is left alive it must keep
an easy handle around internally - only for the purpose of having
an easy handle when it later disconnects it. The code assumed
that when the easy handle was removed and an internal reference
was made, that version could be killed later on when a new easy
handle came using the same connection. This was wrong as Hauke's
example showed that the removed handle wasn't killed for real
until later. This caused a double close attempt => segfault.

which could have caused a double free when reusing curl handle.

  The problem mentioned on Dec 10 2009
  (http://curl.haxx.se/bug/view.cgi?id=2905220) was only partially fixed.
  Partially because an easy handle can be associated with many connections in
  the cache (e.g. if there is a redirect during the lifetime of the easy
  handle).  The previous patch only cleaned up the first one. The new fix now
  removes the easy handle from all connections, not just the first one.

  the easy interface was used.