(http://curl.haxx.se/bug/view.cgi?id=2813123) and an a patch that fixes the
  problem:

  Url A is accessed using auth. Url A redirects to Url B (on a different
  server0. Url B reuses a persistent connection. Url B has auth, even though
  it's on a different server.

  Note: if Url B does not reuse a persistent connection, auth is not sent.

  range if given colon-separated after the host name/address part. Like
  "192.168.0.1:2000-10000"

  (no newline translations). Use -B/--use-ascii if you rather get the ascii
  approach.

  provided in the url, add it there (squid needs this).

  This allows curl(1) to be used as a client-side tunnel for arbitrary stream
  protocols by abusing chunked transfer encoding in both the HTTP request and
  HTTP response.  This requires server support for sending a response while a
  request is still being read, of course.

  If attempting to read from stdin returns EAGAIN, then we pause our sender.
  This leaves curl to attempt to read from the socket while reading from stdin
  (and thus sending) is paused.

  contributed a range of patches to fix them.

  issue with client certs that caused issues like segfaults.
  http://curl.haxx.se/mail/lib-2009-05/0316.html

  to detect gnutls build options with pkg-config only and not libgnutls-config
  anymore since GnuTLS has stopped distributing that tool. If an explicit path
  is given to configure, we will instead guess on how to link and use that
  lib. I did not use the patch from the bug report.

- Added some cmake docs and fixed socklen_t in the build.

  broken since 7.19.0

  is almost always a VERY BAD IDEA. Yet there are still apps out there doing
  this, and now recently it triggered a bug/side-effect in libcurl as when
  libcurl sends a POST or PUT with NTLM, it sends an empty post first when it
  knows it will just get a 401/407 back. If the app then replaced the
  Content-Length header, it caused the server to wait for input that libcurl
  wouldn't send. Aaron Oneal reported this problem in bug report #2799008
  http://curl.haxx.se/bug/view.cgi?id=2799008) and helped us verify the fix.

  without pkg-config.

  PK11_CreateGenericObject() function.

  the auth credentials back in 7.19.0 and earlier while now you have to set ""
  to get the same effect. His patch brings back the ability to use NULL.

  for a failure properly.

  fine with Nokia 5th edition 1.0 SDK for Symbian.

  out that the cookie parser would leak memory when it parses cookies that are
  received with domain, path etc set multiple times in the same header. While
  such a cookie is questionable, they occur in the wild and libcurl no longer
  leaks memory for them. I added such a header to test case 8.

  https://bugzilla.redhat.com/show_bug.cgi?id=427966 which was libcurl closing
  a bad file descriptor when closing down the FTP data connection.  Caolan
  McNamara seems to be the original author of it.

  no_proxy which made it not skip the proxy if the URL entered contained a
  user name. I added test case 1101 to verify.

  of streams that had some parts (legitimately) missing. We now provide and use
  a proper cleanup function for the content encoding submodule.
  http://curl.haxx.se/mail/lib-2009-05/0092.html

  at https://bugzilla.redhat.com/show_bug.cgi?id=453612#c12

  If an incorrect password is given while loading a private key, libcurl ends
  up in an infinite loop consuming memory. The bug is critical.

  as reported by Ebenezer Ikonne (on curl-users) and Laurent Rabret (on
  curl-library). The transfer was mistakenly marked to get more data to send
  but since it didn't actually have that, it just hung there...

to work so I'll let it remain and here's the comment about it! From Lenaic's
mail posted to curl-library Date: Fri, 1 May 2009 22:46:14 +0200.

  (http://curl.haxx.se/bug/view.cgi?id=2784055) identifying a problem to
  connect to SOCKS proxies when using the multi interface. It turned out to
  almost not work at all previously. We need to wait for the TCP connect to
  be properly verified before doing the SOCKS magic.

  There's still a flaw in the FTP code for this.

  reported in the Debian package.

  (http://curl.haxx.se/bug/view.cgi?id=2723236) identifying a problem with
  libcurl's TFTP code and its lack of dealing with the OACK packet.

  corresponding fix in the GnuTLS code: make sure to store the new session id
  in case the re-used one is rejected.

  (http://curl.haxx.se/bug/view.cgi?id=2786255) with a patch, identifying how
  libcurl did not deal with SSL session ids properly if the server rejected a
  re-use of one. Starting now, it will forget the rejected one and remember
  the new. This change was for OpenSSL only, it is likely that other SSL lib
  code needs similar fixes.

David McCreedy's "transfer.c fixes for CURL_DO_LINEEND_CONV and non-ASCII platform HTTP requests" patch

  I've now made TFTP "connections" not being kept for re-use within libcurl.
  TFTP is UDP-based so the benefit was really low (if even existing) to begin
  with so instead of tracking down to fix this problem we instead removed the
  re-use. I also enabled test case 1099 that I wrote a few days ago to verify
  that this change fixes the reported problem.