server using the multi interface, the commands are not being sent correctly
  and instead the connection is "cancelled" (the operation is considered done)
  prematurely. There is a half-baked (busy-looping) patch provided in the bug
  report but it cannot be accepted as-is. See
  http://curl.haxx.se/bug/view.cgi?id=2006544

due to KfW's library header files exporting symbols/macros that should be
kept private to the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/

51.Kevin Reed's reported problem with a proxy when doing CONNECT and it
  wants NTLM and close the connection to the initial CONNECT response:
  http://curl.haxx.se/bug/view.cgi?id=1879375

  crash!

release but hopefully they'll all be fixed in 7.18.1...

a response that was larger than 16KB is now improved slightly so that now
the restriction at 16KB is for the headers only and it should be a rare
situation where the response-headers exceed 16KB. Thus, I consider #47 fixed
and the header limitation is now known as known bug #48.

Added test case 1008 to verify. Note that #47 is still there.

URLs ending with a slash properly (it should list the contents of that
directory). Test case 351 brought back and also test 1010 was added.

  getaddrinfo() sorts the response list which effectively kills how libcurl
  deals with round-robin DNS entries. All details:
    http://curl.haxx.se/mail/lib-2007-07/0168.html
  initial suggested function to use for randomizing the response:
    http://curl.haxx.se/mail/lib-2007-07/0178.html

should list the contents of that directory). See test case 351.

(http://curl.haxx.se/bug/view.cgi?id=1705802), which was filed by Daniel
Black identifying several FTP-SSL test cases fail when we build libcurl with
NSS for TLS/SSL. Listed as #42 in KNOWN_BUGS.

  several FTP-SSL test cases fail when we build libcurl with NSS for TLS/SSL:
  http://curl.haxx.se/bug/view.cgi?id=1705802

  when logging in), the operation will fail since libcurl does detect this and
  thus fails to issue the correct command:
  http://curl.haxx.se/bug/view.cgi?id=1693337

one over to KNOWN_BUGS

test, fixing KNOWN_BUGS #11.  Fixed some tests to more accurately specify
their required servers and features.

New FTP CCC functionality - adds passive and active mode to accomodate for different server behaviour

  5).

  the multi interface and connection re-use that could make a
  curl_multi_remove_handle() ruin a pointer in another handle.

  The second problem was less of an actual problem but more of minor quirk:
  the re-using of connections wasn't properly checking if the connection was
  marked for closure.

  platforms.

  (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.

  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

KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an authentication negotiation. Starting
now, libcurl will re-connect accordingly and continue the authentication as
it should.

supported

  while not fixing things very nicely, it does make the SOCKS5 proxy
  connection slightly better as it now acknowledges the timeout for connection
  and it no longer segfaults in the case when SOCKS requires authentication
  and you did not specify username:password.

CURLOPT_MAX_RECV_SPEED_LARGE that limit tha maximum rate libcurl is allowed
to send or receive data. This kind of adds the the command line tool's
option --limit-rate to the library.

The rate limiting logic in the curl app is now removed and is instead
provided by libcurl itself. Transfer rate limiting will now also work for -d
and -F, which it didn't before.