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.

tests on machines that have broken DNS configurations (such as
those configured to use OpenDNS).

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

  byte in the digest code.

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

  well. See change 28 Apr 2009.

Additionally some identation fixes.

  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 patch to fix test suite harness to allow test FTP server and client on different machines, providing FTP client address when running the FTP test server.

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

report failed to mention that a proxy must be used to reproduce it.

  If the CURLOPT_PORT option is used on an FTP URL like
  "ftp://example.com/file;type=A" the ";type=A" is stripped off.

  I added test case 562 to verify, only to find out that I couldn't repeat
  this bug so I hereby consider it not a bug anymore!

  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.

  (http://curl.haxx.se/bug/view.cgi?id=2783090) pointing out that on windows
  we need to grow the SO_SNDBUF buffer somewhat to get really good upload
  speeds. http://support.microsoft.com/kb/823764 has the details. Friends
  confirmed that simply adding 32 to CURL_MAX_WRITE_SIZE is enough.

  Chen pointed out how curl couldn't upload with resume when reading from a
  pipe.

  This ended up with the introduction of a new return code for the
  CURLOPT_SEEKFUNCTION callback that basically says that the seek failed but
  that libcurl may try to resolve the situation anyway. In our case this means
  libcurl will attempt to instead read that much data from the stream instead
  of seeking and that way curl can now upload with resume when data is read
  from a stream!

  Wegener pointed out that CURLINFO_APPCONNECT_TIME didn't work with the multi
  interface and provided a patch that fixed the problem!

  Koenig pointed out that the man page didn't tell that the *_proxy
  environment variables can be specified lower case or UPPER CASE and the
  lower case takes precedence,

setup_once.h.  Inclusion of each header file is based on the definition of
NEED_MALLOC_H and NEED_MEMORY_H respectively.

  how it occurs (http://curl.haxx.se/mail/lib-2009-04/0289.html). The
  conclusion was that if an error is detected and Curl_done() is called for
  the connection, ftp_done() could at times return another error code that
  then would take precedence and that new code confused existing logic that
  works for the first error code (CURLE_SEND_ERROR) only.

  OBJECTPOINT options. Now we've introduced a new function - my_setopt_str -
  within the app for setting plain string options to avoid the risk of this
  mistake happening.

  proxy. libcurl would then wrongly close the connection after each
  request. In his case it had the weird side-effect that it killed NTLM auth
  for the proxy causing an inifinite loop!

  I added test case 1098 to verify this fix. The test case does however not
  properly verify that the transfers are done persistently - as I couldn't
  think of a clever way to achieve it right now - but you need to read the
  stderr output after a test run to see that it truly did the right thing.

  Storsjo pointed out how setting CURLOPT_NOBODY to 0 could be downright
  confusing as it set the method to either GET or HEAD. The example he showed
  looked like:

   curl_easy_setopt(curl, CURLOPT_PUT, 1);
   curl_easy_setopt(curl, CURLOPT_NOBODY, 0);

  The new way doesn't alter the method until the request is about to start. If
  CURLOPT_NOBODY is then 1 the HTTP request will be HEAD. If CURLOPT_NOBODY is
  0 and the request happens to have been set to HEAD, it will then instead be
  set to GET. I believe this will be less surprising to users, and hopefully
  not hit any existing users badly.