we should make it do that...)

VS2005.

typecast the third argument in the macros to avoid compiler warnings.

.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.

configure. An attempt to fix warnings when we build and the strlcat() function
is provided by one if the libs (gss or krb4) since then we have no protos
for it in a system header.

Archived thread of the help-gnutls mailing list regarding this problem:

http://lists.gnu.org/archive/html/help-gnutls/2005-04/msg00000.html

(and I _am_ sorry for my confused behaviour on this problem.)

bug I thought I saw before when I changed this...!

(missing file, bad file, etc), gnutls will no longer handshake properly but it
just loops forever. Therefore, we must return error if we get an error when
setting the CA cert file name. This is not the same behaviour as with OpenSSL.

Question/report posted to the help-gnutls mailing list, April 8 2005.

internally, with code provided by sslgen.c. All SSL-layer-specific code is
then written in ssluse.c (for OpenSSL) and gtls.c (for GnuTLS).

As far as possible, internals should not need to know what SSL layer that is
in use. Building with GnuTLS currently makes two test cases fail.

TODO.gnutls contains a few known outstanding issues for the GnuTLS support.

GnuTLS support is enabled with configure --with-gnutls

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.