FTP with the multi interface: when a transfer fails, like when aborted by a
  write callback, the control connection was wrongly closed and thus not
  re-used properly.

  This change is also an attempt to cleanup the code somewhat in this area, as
  now the FTP code attempts to keep (better) track on pending responses
  necessary to get read in ftp_done().

connection is kept alive afterwards

  libcurl did a superfluous 1000ms wait when doing SFTP downloads!

  We read data with libssh2 while doing the "DO" operation for SFTP and then
  when we were about to start getting data for the actual file part, the
  "TRANSFER" part, we waited for socket action (in 1000ms) before doing a
  libssh2-read. But in this case libssh2 had already read and buffered the
  data so we ended up always just waiting 1000ms before we get working on the
  data!

FTP downloads (i.e.: RETR) ending with code 550 now return error CURLE_REMOTE_FILE_NOT_FOUND instead of CURLE_FTP_COULDNT_RETR_FILE.

  leak like that fixed on the 14th. When zlib returns failure, we need to
  cleanup properly before returning error.

  plain FTP connections, and it will then allow MKD to fail once and retry the
  CWD afterwards. This is especially useful if you're doing many simultanoes
  connections against the same server and they all have this option enabled,
  as then CWD may first fail but then another connection does MKD before this
  connection and thus MKD fails but trying CWD works! The numbers can
  (should?) now be set with the convenience enums now called
  CURLFTP_CREATE_DIR and CURLFTP_CREATE_DIR_RETRY.

  Tests has proven that if you're making an application that uploads a set of
  files to an ftp server, you will get a noticable gain in speed if you're
  using multiple connections and this option will be then be very useful.

when an 'int' is assigned to a 'time_t' variable. Hence redefine 'retry_time'
and 'retry_max' to 'time_t'.

copyright-update script thinks

  code, which could happen on libz errors.

poned

ltoptions.m4 ltsugar.m4 ltversion.m4 lt~obsolete.m4

  the condition in the previous request was unmet. This is typically a time
  condition set with CURLOPT_TIMECONDITION and was previously not possible to
  reliably figure out. From bug report #2565128
  (http://curl.haxx.se/bug/view.cgi?id=2565128)

to better know and track symbols in earlier libcurl versions

   getaddrinfo() sorts the response list

This isn't a libcurl bug since this is how getaddrinfo() is *supposed* to work!
Apparently you deal with this using the /etc/gai.conf file.

later)

functions are.

patch declined

This couldn't ever overflow in curl, but might if the code were used
elsewhere or under different conditions.