multi interface, but I could also repeat it doing multiple sequential ones
with the easy interface. Using Ciprian's test case, I could fix it.

CURLOPT_VERBOSE set to non-zero, you still got a few debug messages from the
SSL handshake. This is now stopped.

wrong error message in the error message buffer.

This was possible on debug c-ares enabled builds when both CURL_MEMDEBUG
and CARES_MEMDEBUG environment variables were set. Leading to a file handle
leak even when both variables had the same value, and wierd test suite
results when different.

KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an authentication negotiation. Starting
now, libcurl will re-connect accordingly and continue the authentication as
it should.

a fatal bug so we must require 1.3.2 to get flawless functionality with c-ares.

compiler warning fix since it was Ok and actually
avoids the targeted compiler warning.

Assigning the const value zero to a pointer to function
results in a null pointer value assignment to the function
pointer.

Assignment of any nonzero value is what should result in a
implementation compiler dependent result.

Since what we want to do here is the first case, this should
not trigger compiler warnings related with conversions from
'pointer to data' to 'pointer to function'.

Our autobuild test suite will judge.

and send(). Added needed HAVE_x defines.

to avoid picky compiler warnings, since this is what we want!

buffer used to store headers in the SessionHandle failed.

case when 401 or 407 are returned, *IF* no auth credentials have been given.
The CURLOPT_FAILONERROR option is not possible to make fool-proof for 401
and 407 cases when auth credentials is given, but we've now covered this
somewhat more.

You might get some amounts of headers transferred before this situation is
detected, like for when a "100-continue" is received as a response to a
POST/PUT and a 401 or 407 is received immediately afterwards.

Added test 281 to verify this change.

applies for asynch name resolves in general and not only ares

re-use connections (for pipelining) before the name resolving is done.

as well

reading the (local) CA cert file to let users easier pinpoint the actual
problem. CURLE_SSL_CACERT_BADFILE (77) is the new libcurl error code.

(when the resoling isn't completede yet) and not confuse it with a simple
connection re-use (non-pipelined).

to verify winsock API availability.

using winsock or winsock2 API.