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.

  strdup() call failed.

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

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

  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.

  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)

  version 1.1 instead of 1.0 like before. This change also introduces the new
  proxy type for libcurl called 'CURLPROXY_HTTP_1_0' that then allows apps to
  switch (back) to CONNECT 1.0 requests. The curl tool also got a --proxy1.0
  option that works exactly like --proxy but sets CURLPROXY_HTTP_1_0.

  I updated all test cases cases that use CONNECT and I tried to do some using
  --proxy1.0 and some updated to do CONNECT 1.1 to get both versions run.

the problem.

clarity.  This does fix one problem that causes ;type=i FTP URLs
to fail in the Turkish locale when CURLOPT_PROXY_TRANSFER_MODE is
used (test case 561)

Added tests 561 and 1092 through 1094 to test various combinations
of ;type= and ;mode= URLs that could potentially fail in the Turkish
locale.

  now has an improved ability to do right when the multi interface (both
  "regular" and multi_socket) is used for SCP and SFTP transfers. This should
  result in (much) less busy-loop situations and thus less CPU usage with no
  speed loss.

  particular state for the control connection like it did before for implicit
  FTPS (libcurl assumed such control connections to be encrypted while some
  FTPS servers such as FileZilla assumes such connections to be clear
  mode). Use the CURLOPT_USE_SSL option to set your desired level.

  researching it, it turned out he got a 550 response back from a SIZE command
  and then I fell over the text in RFC3659 that says:

   The presence of the 550 error response to a SIZE command MUST NOT be taken
   by the client as an indication that the file cannot be transferred in the
   current MODE and TYPE.

  In other words: the change I did on September 30th 2008 and that has been
  included in the last two releases were a regression and a bad idea. We MUST
  NOT take a 550 response from SIZE as a hint that the file doesn't exist.

which now also takes a protocol address family argument.

Changed checkprefix() to use it and those instances of strnequal() that
compare host names or other protocol strings that are defined to be
independent of case in the C locale.  This should fix a few more
Turkish locale problems.

run-time relocations.

systems supporting getifaddrs(). Also fixed a problem where an IPv6
address could be chosen instead of an IPv4 one for --interface when it
involved a name lookup.

  gets a 550 response back for the cases where a download (or NOBODY) is
  wanted. It still allows a 550 as response if the SIZE is used as part of an
  upload process (like if resuming an upload is requested and the file isn't
  there before the upload). I also modified the FTP test server and a few test
  cases accordingly to match this modified behavior.

  libcurl to somewhat reduce the size of the binary. Run configure
  --disable-proxy.

706 and 707.

remain in use as internal curl_off_t print formatting strings for the internal
*printf functions which still cannot handle print formatting string directives
such as "I64d", "I64u", and others available on MSVC, MinGW, Intel's ICC, and
other DOS/Windows compilers.

This reverts previous commit part which did:

FORMAT_OFF_T  -> CURL_FORMAT_CURL_OFF_T
FORMAT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU

the names of the curl_off_t formatting string directives now become
CURL_FORMAT_CURL_OFF_T and CURL_FORMAT_CURL_OFF_TU.

CURL_FMT_OFF_T  -> CURL_FORMAT_CURL_OFF_T
CURL_FMT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU

Remove the use of an internal name for the curl_off_t formatting string directives
and use the common one available from the inside and outside of the library.

FORMAT_OFF_T  -> CURL_FORMAT_CURL_OFF_T
FORMAT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU

line of a multiline FTP response whose last byte landed exactly at the end
of the BUFSIZE-length buffer would be treated as the terminal response
line.  The following response code read in would then actually be the
end of the previous response line, and all responses from then on would
correspond to the wrong command. Test case 1062 verifies this.

Stop closing a never-opened ftp socket.

  fix for it. It occured when you did a FTP transfer using
  CURLFTPMETHOD_SINGLECWD and then did another one on the same easy handle but
  switched to CURLFTPMETHOD_NOCWD. Due to the "dir depth" variable not being
  cleared properly.  Scott's test case is now known as test 539 and it
  verifies the fix.

  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480044) identifying a
  segfault when using krb5 ftp, but the krb4 code had the same problem.

  libcurl" (http://curl.haxx.se/bug/view.cgi?id=1951588) which seems to be an
  identical report to what Denis Golovan reported in
  http://curl.haxx.se/mail/lib-2008-02/0108.html The FTP code didn't reset the
  user/password pointers properly even though there might've been a new
  struct/cconnection getting used.

  message when libcurl doesn't get a 220 back immediately on connect, I now
  changed it to be more specific on what the problem is. Also worth noticing:
  while the bug report contains an example where the response is:

    421 There are too many connected users, please try again later

  we cannot assume that the error message will always be this readable nor
  that it fits within a particular boundary etc.