least it should no longer cause a compiler error. However, it does not have
AI_NUMERICHOST so we cannot getaddrinfo() any numerical addresses with it (we
use that for FTP PORT/EPRT)! So, I modified the configure check that checks if
the getaddrinfo() is working, to use AI_NUMERICHOST since then it'll fail on
AIX 4.3 and it will automatically build with IPv6 support disabled.

--trace, --trace-ascii and --verbose output. I also made the '>' display
separate each line on the linefeed so that HTTP requests etc look nicer in the
-v output.

more places. First, CURL_HOME is a new environment variable that is used
instead of HOME if it is set, to point out where the default config file
lives. If there's no config file in the dir pointed out by one of the
environment variables, the Windows version will instead check the same
directory the executable curl is located in.

.netrc, and when following a Location: the subsequent requests didn't properly
use the auth as found in the netrc file. Added test case 257 to verify my fix.

*/setup.h and */config-win32.h to build fine with VS2005 on x64.

used the default port. He was right. I fixed the problem and added the test
cases 521, 522 and 523 to verify the fix.

libcurl didn't properly send an Expect: 100-continue header. It does now.

also affecting NTLM and Negotiate.) It turned out that if the server responded
with 100 Continue before the initial 401 response, libcurl didn't take care of
the response properly. Test case 245 and 246 added to verify this.

  inet_addr() functions seems to use &255 on all numericals in a ipv4 dotted
  address which makes a different failure... Now I've modified the ipv4
  resolve code to use inet_pton() instead in an attempt to make these systems
  better detect this as a bad IP address rather than creating a toally bogus
  address that is then passed on and used.

USE_WINDOWS_SSPI on Windows, and then libcurl will be built to use the native
way to do NTLM. SSPI also allows libcurl to pass on the current user and its
password in the request.

file got a Last-Modified: header written to the data stream, corrupting the
actual data. This was because some conditions from the previous FTP code was
not properly brought into the new FTP code. I fixed and I added test case 520
to verify. (This bug was introduced in 7.13.1)

on the remote side. This then converts the operation to an ordinary STOR
upload. This was requested/pointed out by Ignacio Vazquez-Abrams.

It also proved (and I fixed) a bug in the newly rewritten ftp code (and
present in the 7.13.1 release) when trying to resume an upload and the servers
returns an error to the SIZE command. libcurl then loops and sends SIZE
commands infinitely.

the cookie "engine" without having to provide an empty or non-existing file.

requested data from a host and then followed a redirect to another
host. libcurl then didn't use the proxy-auth properly in the second request,
due to the host-only check for original host name wrongly being extended to
the proxy auth as well. Added test case 233 to verify the flaw and that the
fix removed the problem.

that picks NTLM. Thanks to David Byron letting me test NTLM against his
servers, I could quickly repeat and fix the problem. It turned out to be:

When libcurl POSTs without knowing/using an authentication and it gets back a
list of types from which it picks NTLM, it needs to either continue sending
its data if it keeps the connection alive, or not send the data but close the
connection. Then do the first step in the NTLM auth. libcurl didn't send the
data nor close the connection but simply read the response-body and then sent
the first negotiation step. Which then failed miserably of course. The fixed
version forces a connection if there is more than 2000 bytes left to send.

week day names and month names and servers don't like that.