Merge tag 'curl-7_38_0'

curl 7.38.0
Merge branch 'master' of git://github.com/bagder/curl
Debug output 'typo' fix.

Don't print an extra "0x" in
* Pipe broke: handle 0x0x2546d88, url = /
Don't add new requests to a closed pipeline.

This single commit fixes seemingly all problems that I had:
After a requests times out it marks the conn(ection) as 'close'
by calling connclose() and then stopped handling the easy
handle *completely* - hence the connection is never (really)
closed, the bundle is kept alive and never removed, and with
this commit a following active request creates a new connection
in the bundle, which is the one being used after that - because
the one that had 'close' set is skipped.

However, this -therefore- leaks: the connection is never closed
(by the client), nothing is cleaned up.

After the commits that follow, this commit is no longer needed,
but it makes sense to keep it; after all: we really do NOT ever
want to use a connection that is marked as 'close' here.

The remaining problem: leaking and not closing the socket is
addressed in the following commits.
Fix a leak and close the connection of a request that timed out.

This fixes a four year old bug; when a request times out, then
setting CURLM_STATE_COMPLETED here, followed by a break, causes
the code to continue at the end of the function where the
message is sent to the user with multi_addmsg() after which
the state is set to CURLM_STATE_MSGSENT.

An easy handle in that state never gets out of that state anymore:
the state does nothing. Cleaning up the easy handle from the user
application (after seeing the request is CURLMSG_DONE) doesn't
change that fact. As a result, the easy handle gets stuck, owning
a connection set to 'close' that is never closed or cleaned up.

This commit set to the state to CURLM_STATE_DONE and does NOT break
out of the loop. As a result the easy handle is cleaned up as a
handle with an error, as it should. It's connection is closed.

However, problems remain after this:
1) Because this was (likely) the last connection, the bundle is deleted
   as well now; which results in libcurl forgetting that this server
   can do pipelining. The new connection that is created for subsequent
   requests, or for handles in the pipeline after this one that didn't
   time out cause new connections to be created until we finally
   receive headers for one of them. This is a random process and we
   can end up any arbitrary number of connections; which afterwards
   will NOT desolve itself (they will all kept being used).
2) The requests that were still in the pipeline will attempt a new
   connection - then discover they have timed out and ALSO call
   connclose, causing the JUST created fresh connection to be closed
   too. The result is a rapid brust of calls to connect() and close().

Both problems are addressed in subsequent commits because they are
exclusively pipeline related, while this commit isn't.
On timeout, do not close connections with NO pending data.

When pipelining it is possible that a request never reached
the DO state, but still timed out because a request in the pipeline
before it took a long time.

The logic of curl is such that first a new connection is created
and only then the handles on it are checked for time outs, hence
it is possible that a handle times out without ever having sent
a GET request over their connection. In that case we don't want
to close that connection: it is a healthy connection that probably
was JUST created as replacement for the broken pipe at which the
timeout really occurred.

Although this commit fixes the burst of connect()/close() calls,
the problem remains that the bundle to the server was refreshed,
so curl forgot about this server being able to do pipelining.
This is fixed in the next commit.
Prevent a bundle being deleted while closing a broken pipe.

If a request on a pipe times out, it breaks that pipe: the
connection needs to be closed. However, when doing http pipelining
we really don't want to delete the bundle and forget that this
server can do pipelining because that results in a separate connection
for every handle in the pipeline that didn't timeout yet, plus one
for every handle that is added until we receive new headers from the
server again, potentially a lot.

The user application could battle this a little bit by holding back
on adding new requests when it sees a timeout, until it saw a reply
again from the server - but that is an extra burden on the user
application that is unnecessary. Besides, that doesn't guarantee that
multiple connections wonn't formed due to requests already in the
pipe that didn't timeout yet (i.e. because they were added later than
the one that did).

Although theoretically this is still a leak of the bundle (though note
that before this series of commits it was ALREADY leaking), in practice
a new request WILL*) be added and the bundle will be reused without any
trace of a leak.
*) After all, we're talking about a pipelining server here :p.
Merge branch 'master' of github-carlo:CarloWood/curl