John-Mark Bell filed bug #3000052 that identified a problem (with
an associated patch) with the OpenSSL handshake state machine
when the multi interface is used:

Performing an https request using a curl multi handle and using
select or epoll to wait for events results in a hang. It appears
that the cause is the fix for bug #2958179, which makes
ossl_connect_common unconditionally return from the step 2 loop
when fetching from a multi handle.

When ossl_connect_step2 has completed, it updates
connssl->connecting_state to ssl_connect_3. ossl_connect_common
will then return to the caller, as a multi handle is in
use. Eventually, the client code will call curl_multi_fdset to
obtain an updated fdset to select or epoll on. For https
requests, curl_multi_fdset will cause https_getsock to be called.
https_getsock will only return a socket handle if the
connecting_state is ssl_connect_2_reading or
ssl_connect_2_writing.  Therefore, the client will never obtain a
valid fdset, and thus not drive the multi handle, resulting in a
hang.

(http://curl.haxx.se/bug/view.cgi?id=3000052)

Sebastian V reported bug #3000056 identifying a problem with
redirect following. It showed that when curl followed redirects
it didn't properly ignore the response body of the 30X response
if that response was using compressed Content-Encoding!

(http://curl.haxx.se/bug/view.cgi?id=3000056)

"The BSD version of PolarSSL was made for migratory purposes only and is not
maintained. The GPL version of PolarSSL is actually the only actively
developed version, so I would be very reluctant to use the BSD version." /
Paul Bakker, PolarSSL hacker.

Signed-off-by: Hoi-Ho Chan <hoiho.chan@gmail.com>

I didn't bother with a few that have little hope of running the required
dependent libraries.

librtmp is found at http://rtmpdump.mplayerhq.hu/

FTP(S) use two connections that can be set to different recv and
send functions independently, so by introducing recv+send pairs
in the same manner we already have sockets/connections we can
work with FTPS fine.

This commit fixes the FTPS regression introduced in change d64bd82b.

Kalle Vahlman's patch applied a while ago broke how the findtool
function searches for tools, as it would always check if "$file"
was present first, which thus made the bad assumption that a file
in the current directory would be a match.

I noticed when it found 'libtool' in the current directory but
libtoolize is not there, which confused the script.

Dirk Manske reported a regression. When connecting with the multi
interface, there were situations where libcurl wouldn't store
connect time correctly as it used to (and is documented to) do.

Using his fine sample program we could repeat it, and I wrote up
test case 573 using that code. The problem does not easily show
itself using the local test suite though.

The fix, also as suggested by Dirk, is a bit on the ugly side as
it adds yet another call to Curl_verboseconnect() and setting the
TIMER_CONNECT time.  That situation is subject for some closer
inspection in the future.

As the function is used more than once and libcurl can be built
without it, do the conditional check within the verboseconnect()
function itself.

Howard Chu brought the bulk work of this patch that properly
moves out the sending and recving of data to the parts of the
code that are properly responsible for the various ways of doing
so.

Daniel Stenberg assisted with polishing a few bits and fixed some
minor flaws in the original patch.

Another upside of this patch is that we now abuse CURLcodes less
with the "magic" -1 return codes and instead use CURLE_AGAIN more
consistently.

This is Hoi-Ho Chan's patch with some minor fixes by me. There
are some potential issues in this, but none worse than we can
sort out on the list and over time.

... and GnuTLS connects are non-blocking, TFTP is better
integrated as a "real" protocol and RTSP is supported.

Since commit c2888604 by Jerome Vouillon

It's not quite fair to list TFTP is a "crappy" member of the
libcurl family so I removed its mentioning.

The main change is to allow input from user-specified methods,
when they are specified with CURLOPT_READFUNCTION.
All calls to fflush(stdout) in telnet.c were removed, which makes
using 'curl telnet://foo.com' painful since prompts and other data
are not always returned to the user promptly.  Use
'curl --no-buffer telnet://foo.com

' instead.  In general,
the user should have their CURLOPT_WRITEFUNCTION do a fflush
for interactive use.

Also fix assumption that reading from stdin never returns < 0.
Old code could crash in that case.

Call progress functions in telnet main loop.

Signed-off-by: Ben Greear <greearb@candelatech.com>