address, the one on the box libcurl is running, not the 'remote' one.

used, and define HAVE_IOCTL_SIOCGIFADDR if appropriate.

calls. Added a paragraph explaining that libcurl takes care of low-level
protocol details. Made a few minor edits.

enabled and FTP disabled.

codes for all calls to malloc and strdup that were missing. I also changed
a few malloc(13) to use arrays on the stack and a few malloc(PATH_MAX) to
instead use aprintf() to lower memory use.
I also fixed a memory leak in Curl_nss_connect() when CURLOPT_ISSUERCERT is
in use.

as a known-working environment.

fix compilation on Cell (reported by Jeff Curley).

form generator.  Made the extensions part of the MIME type struct to reduce
the size and run-time relocations necessary to build the table.

also prevent buffer overflow on MSDOS when you do for example -O on a url
with a file name part longer than PATH_MAX letters

We do testing of code functions using the test suite instead!

checks for inet_ntoa_r() inet_ntop() and inet_pton()

non-blocking mode, and decouple function detection from function capability.

  paused.

while still causing a timeout during the data phase.

  (http://curl.haxx.se/bug/view.cgi?id=2255627) which pointed out that a
  program using libcurl's multi interface to download a HTTPS page with a
  libcurl built powered by OpenSSL, would easily get silly and instead hand
  over SSL details as data instead of the actual HTTP headers and body. This
  happened because libcurl would consider the connection handshake done too
  early. This problem was introduced at September 22nd 2008 with my fix of the
  bug #2107377

  The correct fix is now instead done within the GnuTLS-handling code, as both
  the OpenSSL and the NSS code already deal with this situation in similar
  fashion. I added test case 560 in an attempt to verify this fix, but
  unfortunately it didn't trigger it even before this fix!

either sorted out or more/new details come up

This test was added after the HTTPS-using-multi-interface with OpenSSL
regression of 7.19.1 to hopefully prevent this embarassing mistake from
appearing again... Unfortunately the bug wasn't triggered by this test, which
presumably is because the connect to a local server is too fast/different
compared to the real/distant servers we saw the bug happen with.