curl that uses the new CURLOPT_FTP_SSL_CCC option in libcurl. If enabled, it
  will make libcurl shutdown SSL/TLS after the authentication is done on a
  FTP-SSL operation.

function(s) using SessionHandle pointers

  non-ASCII platforms.

  downloaded data in two buffers, just to be able to deal with a special HTTP
  pipelining case. That is now only activated for pipelined transfers. In
  Matt's case, it showed as a considerable performance difference,

  (http://curl.haxx.se/bug/view.cgi?id=1603712) (known bug #36) --limit-rate
  (CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARGE) are broken
  on Windows (since 7.16.0, but that's when they were introduced as previous
  to that the limiting logic was made in the application only and not in the
  library). It was actually also broken on select()-based systems (as apposed
  to poll()) but we haven't had any such reports. We now use select(), Sleep()
  or delay() properly to sleep a while without waiting for anything input or
  output when the rate limiting is activated with the easy interface.

  to get built static. It has been mentioned before and was again brought to
  our attention by Nathanael Nerode who filed debian bug report #405226
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405226).

  get confused and not acknowledge the 'no_proxy' variable properly once it
  had used the proxy and you re-used the same easy handle. I made sure the
  proxy name is properly stored in the connect struct rather than the
  sessionhandle/easy struct.

  variable to point to when it should be a socklen_t.

'curl [URL]' with a URL without a protocol prefix, curl would not send a
correct request as it failed to add the protocol prefix.

(http://curl.haxx.se/bug/view.cgi?id=1618359) and subsequently provided a
patch for it: when downloading 2 zero byte files in a row, curl 7.16.0
enters an infinite loop, while curl 7.16.1-20061218 does one additional
unnecessary request.

Fix: During the "Major overhaul introducing http pipelining support and
shared connection cache within the multi handle." change, headerbytecount
was moved to live in the Curl_transfer_keeper structure. But that structure
is reset in the Transfer method, losing the information that we had about
the header size. This patch moves it back to the connectdata struct.

* added mentioning of doing the stunnel equivalent ourselves for the test suite
* spell-check

  authentication (with performs multiple "passes" and authenticates a
  connection rather than a HTTP request), and particularly when using the
  multi interface, there's a risk that libcurl will re-use a wrong connection
  when doing the different passes in the NTLM negotiation and thus fail to
  negotiate (in seemingly mysterious ways).

36. --limit-rate (CURLOPT_MAX_SEND_SPEED_LARGE and
  CURLOPT_MAX_RECV_SPEED_LARGE) are broken on Windows (since 7.16.0, but
  that's when they were introduced as previous to that the limiting logic was
  made in the application only and not in the library). This problem is easily
  repeated and it takes a Windows person to fire up his/hers debugger in order
  to fix. http://curl.haxx.se/bug/view.cgi?id=1603712

Brendan Jurd pointed out.

during certain conditions when GnuTLS is used.

something went wrong like it got a bad response code back from the server,
libcurl would leak memory. Added test case 538 to verify the fix.

I also noted that the connection would get cached in that case, which
doesn't make sense since it cannot be re-use when the authentication has
failed. I fixed that issue too at the same time, and also that the path
would be "remembered" in vain for cases where the connection was about to
get closed.

include the protocol bits of such actions, which currently only means FTP

temporarily higher speeds than requested, but the given limiting is considered
"over time" and is an average

(http://curl.haxx.se/bug/view.cgi?id=1603712) which is about connections
getting cut off prematurely when --limit-rate is used. While I found no such
problems in my tests nor in my reading of the code, I found that the
--limit-rate code was severly flawed (since it was moved into the lib, since
7.15.5) when used with the easy interface and it didn't work as documented so
I reworked it somewhat and now it works for my tests.