(http://curl.haxx.se/bug/view.cgi?id=1561470) that is said to crash when an
FTP upload fails with the multi interface. It did not, but I made a failed
upload still assume the control connection to be fine.

empty password or no password at all. Test case 278 and 279 were added to
verify.

FTPS

it basically was that we didn't remove the current connection from the pipe
list when following a redirect. Also in this commit: several cases of
additional debug code for debug builds helping to check and track down some
signs of run-time trouble.

currently fits in the cache, to make the cache work better especially for
pipelining cases but also for "mere" (persistent) connection re-use.

is still trying to resolve the host name, it seems that the ftp struct is not
yet initialized, but the removal action calls Curl_done() which calls
Curl_ftp_done. So we simply return success from there if no ftp pointer is
set.

Curl_signalPipeClose is now signalPipeClose().

all Win32 targets except CygWin. Cleanup.

FTP 3rd party transfers to that file for now until I have them sorted out.

we certainly MUST NOT kill an active connection... Problem tracked down thanks
to Michael Wallner's excellent test program.

  (ares_init.c/get_iphlpapi_dns_info() function): when I disable the network
  by hand or disconnect the network cable in Windows 2000 or Windows XP, my
  application gets 127.0.0.1 as the only name server. The problem comes from
  'GetNetworkParams' function, that returns the empty string "" as the only
  name server in that case. Moreover, the Windows implementation of
  inet_addr() returns INADDR_LOOPBACK instead of INADDR_NONE.

  handle that is part of a multi handle first removes the handle from the
  stack.

- Added CURLOPT_SSL_SESSIONID_CACHE and --no-sessionid to disable SSL
  session-ID re-use on demand since there obviously are broken servers out
  there that misbehave with session-IDs used.

  problem with it (SIGSEGV-style). It clearly showed that the existing
  socket-state and state-difference function wasn't good enough so I rewrote
  it and could then re-run Jeff's program without any crash. The previous
  version clearly could miss to tell the application when a handle changed
  from using one socket to using another.

  While I was at it (as I could use this as a means to track this problem
  down), I've now added a 'magic' number to the easy handle struct that is
  inited at curl_easy_init() time and cleared at curl_easy_cleanup() time that
  we can use internally to detect that an easy handle seems to be fine, or at
  least not closed or freed (freeing in debug builds fill the area with 0x13
  bytes but in normal builds we can of course not assume any particular data
  in the freed areas).

"dump" a hash table which is useful when tracking problems with data stored
in one of our hashes.

Winsock.