On Thu, 6 Nov 2014, Carlo Wood wrote:

> Also don't delete the bundle when a connection closed that is marked for
> retry. The retry will pick up the bundle again, so we still know if it
> supports pipelining or not; which is much better than having to detect
> that all over again.
> ---
> lib/multi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/multi.c b/lib/multi.c
> index fde54fa..50c4cf8 100644
> --- a/lib/multi.c
> +++ b/lib/multi.c
> @@ -1660,7 +1660,8 @@ static CURLMcode multi_runsingle(struct Curl_multi *multi,
> capable of pipelining. */
> bundle = data->easy_conn->bundle;
> keep_bundle = (bundle->server_supports_pipelining &&
> - data->result == CURLE_OPERATION_TIMEDOUT);
> + (data->result == CURLE_OPERATION_TIMEDOUT ||
> + data->easy_conn->bits.retry));
> if(keep_bundle)
> ++bundle->num_connections;

Okay, but... As regards this and the previous patch, it feels
like optimizing a case that is out in the long tail. More than
that, under a timeout or a retry situation, you might actually
*want* a more conservative response. Throw the bundle away and
get a fresh set of state.

To the libcurl devs... I kind of suspect a more unusual
problem in the retry logic. I was playing with something
like GET with request body generated via READFUNCTION and
I was having a lot of protocol corruption. Looked like
libcurl was failing to notice that I didn't have an
IOCTLFUNCTION or SEEKFUNCTION callback in this scenario to
do a rewind on the request body and just sent out a plain
bodyless GET.

m

--
Monty Brandenberg, Software Engineer                               MCB, Inc.
mcbinc_at_panix.com                                             P.O. Box 425292
mcbinc_at_pobox.com                                   Cambridge, MA  02142-0006
617.864.6907
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html