There was a problem when a UNIX-like server returned information
about directory size (total NNNNNN) at the first line of
response.

When a hostname resolves to multiple IP addresses and the first one
tried doesn't work, the socket for the second attempt may get dropped on
the floor, causing the request to eventually time out. The issue is that
when using kqueue (as on mac and bsd platforms) instead of select, the
kernel removes the first fd from kqueue when it is closed (in trynextip,
connect.c:503). Trynextip() then goes on to open a new socket, which
gets assigned the same number as the one it just closed. Later in
multi.c, socket_cb is not called because the fd is already in
multi->sockhash, so the new socket is never added to kqueue.

The correct fix is to ensure that socket_cb is called to remove the fd
when trynextip() closes the socket, and again to re-add it after
singleipsocket(). I'm not sure how to cleanly do that, but the attached
patch works around the problem in an admittedly kludgy way by delaying
the close to ensure that the newly-opened socket gets a different fd.

Daniel's added comment: I didn't spot a way to easily do a nicer fix so
I've proceeded with Ben's patch.

Bug: http://curl.haxx.se/bug/view.cgi?id=3017819
Patch by: Ben Darnell

It was broken for URLs like "ftp://example.com/".

It passes the git log output through 'log2changes.pl' to produce
the lot.

CHANGES is no longer used for manually edited content. It is to
be generated automatically by maketgz when we make release
tarballs.

--decorate=full is needed with my git 1.7.1 to get the necessary
output so that the previous edit would work to extract the
Version stuff.

... but I had to edit how the refs/tags was extracted since it
had a little flaw that made it miss the 7.20.1 output.

Finally, I changed so that Version is outputted even more similar
to how CHANGES does it.

Add the ASCII art header, and list version commits by decoding
the ref tag names, when available (using the git log --decorate
option).

$ git log --pretty=fuller --no-color --date=short | ./log2changes.pl

Of course, limiting the log output with a range like with
"[tag]..HEAD" appended can be very useful too.

For example the libssh2 based functions return other negative
values than -1 to signal errors and it is important that we catch
them properly. Right before this, various failures from libssh2
were treated as negative download amounts which caused havoc.

My additional call to Curl_pgrsUpdate() would sometimes get
called even though there's no connection (left) so a NULL pointer
would get passed, causing a segfault.

Reported-by: Steven M. Schweda

1) no need to call the progress function twice when in the
CURLM_STATE_TOOFAST state.

2) Make sure that the progress callback's return code is
acknowledged when used

As long as no error is reported, the progress function can get
called. This may be a little TOO often so we should keep an eye
on this and possibly make this conditional somehow.

Previously we only accepted the option when named
--disable-threaded-resover, which wasn't quite intended.

Reported by: Helwing Lutz

There is an implicit conversion from "unsigned long" to "long";
rounding, sign extension, or loss of accuracy may result.

Fixed by an added typecast.

Curl_fillreadbuffer()'s second argument takes an int, so
typecasting to another is a bad idea.

Older unixes want an 'int' instead of 'size_t' as the 3rd
argumment so before this change it would cause warnings such as:

There is an implicit conversion from "unsigned long" to "int";
rounding, sign extension, or loss of accuracy may result.

Signed-off-by: Diego Casorran <dcasorran@gmail.com>

Was seeing spurious SSL connection aborts using libcurl and
OpenSSL. I tracked it down to uncleared error state on the
OpenSSL error stack - patch attached deals with that.

Rough idea of problem:

Code that uses libcurl calls some library that uses OpenSSL but
don't clear the OpenSSL error stack after an error.

ssluse.c calls SSL_read which eventually gets an EWOULDBLOCK from
the OS. Returns -1 to indicate an error

ssluse.c calls SSL_get_error. First thing, SSL_get_error calls
ERR_get_error to check the OpenSSL error stack, finds an old
error and returns SSL_ERROR_SSL instead of SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE.

ssluse.c returns an error and aborts the connection

Solution:

Clear the openssl error stack before calling SSL_* operation if
we're going to call SSL_get_error afterwards.

Notes:

This is much more likely to happen with multi because it's easier
to intersperse other calls to the OpenSSL library in the same
thread.