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.

  them all use the same (hopefully correct) logic to make it less error-prone
  and easier to introduce library-wide where it should be used.

  the SingleRequest one to make pipelining better. It is a bit tricky to keep
  them in the right place, to keep things related to the actual request or to
  the actual connection in the right place.

function itself adds that. Fixed on 50 or something strings!

libcurl to seek in a given input stream. This is particularly important when
doing upload resumes when there's already a huge part of the file present
remotely. Before, and still if this callback isn't used, libcurl will read
and through away the entire file up to the point to where the resuming
begins (which of course can be a slow opereration depending on file size,
I/O bandwidth and more). This new function will also be preferred to get
used instead of the CURLOPT_IOCTLFUNCTION for seeking back in a stream when
doing multi-stage HTTP auth with POST/PUT.

Use TRUE/FALSE from setup_once.h.

is an inofficial PROXY4 variant that sends the hostname to the proxy instead
of the resolved address (which is already supported by SOCKS5).  --socks4a is
the curl command line option for it and CURLOPT_PROXYTYPE can now be set to
CURLPROXY_SOCKS4A as well.

use that prefix as we use that prefix only for library-wide internal global
symbols.

returns a full buffer on each invoke.

is inited at the start of the DO action. I removed the Curl_transfer_keeper
struct completely, and I had to move out a few struct members (that had to
be set before DO or used after DONE) to the UrlState struct. The SingleRequest
struct is accessed with SessionHandle->req.

One of the biggest reasons for doing this was the bunch of duplicate struct
members in HandleData and Curl_transfer_keeper since it was really messy to
keep track of two variables with the same name and basically the same purpose!