the initial connect to "come through".

This should work fine for connect and for FTP-PASV connects. Needs massive
testing.

of time!

it to NULL and then use the internal default instead. It will always be
a function to call.

for receiving data from the network. It is meant as a hint, not as a forced
limit.

  faster on Windows when removing the 1 microsecond timeout.

case a timeout is set. This seems to work. God knows if it is good enough
or what kind of side-effects we introduce here and now.

I'll close my eyes and cross my fingers. Hard.

we might actually re-use a connection to a different host, when using proxies!

This was what bug report #558888 was all about.

any name resolved data in any curl handle struct. That way, we won't mind
if the cache entries are pruned for the next time we need them. We'll just
resolve them again instead.

This changes the Curl_resolv() proto. It modifies the SessionHandle struct
but perhaps most importantly, it'll make the internals somewhat dependent
on the DNS cache not being disabled as that will cripple operations somewhat.
Especially for persistant connections.

from the host names before comparing

better for FTP (any protocol with protocol-specific connect actions)

CURLOPT_DEBUGFUNCTION and CURLOPT_DEBUGDATA.

check proxy connections for "deadness" before they were re-used

NULL set back the internal default function

request of its own, it just changes the keyword of a request.

The default cache timeout for this is 60 seconds, which is arbitrary and
completely subject to change :)

    - Use a global dns cache (via setting the tentatively named,
    CURLOPT_DNS_USE_GLOBAL_CACHE option to true)
    - Use a per-handle dns cache, by default
    - Use a pooled dns cache when in the "multi" interface

platforms that have such a function.
This affects multi-thread running libcurls on IPv4 systems that have VERBOSE
switched on. The previous version was risking that another thread overwrote
the data before it was read out in this thread. There could possibly also
be a slight risk that the data isn't zero terminated for a short while and
thus could cause the thread to crash...