from url.c: Curl_disconnect().

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.

send any data anyway. Probably the bug Tom Moers noticed.

AUTH has been received successfully.

up in several chunks when read.

function was fixed to use the proper proxy authentication when multiple ones
were added as accepted. test 239 and test 243 were added to repeat the
problems and verify the fixes.

more involved, but should hopefully not generate any compiler warnings on
win32 systems (that can't check the socket based on the numeric).

scripts use the version in packages/vms/

  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.

never executed code when -Wunreachable-code is used

for SSPI support. The contents of the file has been moved into the krb4.h file.

the correct dynamic library names by default, and provides override switches
--with-ldap-lib, --with-lber-lib and --without-lber-lib.  Added
CURL_DISABLE_LDAP to platform-specific config files to disable LDAP
support on those platforms that probably don't have dynamic OpenLDAP
libraries available to avoid compile errors.

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.

referencing the proxy name pointer.

that feature 64 bit 'long'.

Some systems have 64 bit time_t and deal with years beyond 2038. However, even
some of the systems with 64 bit time_t returns -1 for dates beyond 03:14:07
UTC, January 19, 2038. (Such as AIX 5100-06)

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.