Re: [PATCH] remote-curl: Include curl_errorstr on SSL setup failures

From: Shawn Pearce <spearce@spearce.org>
Date: Feb 14, 2016, 18:04 UTC
Message-ID: <CAJo=hJsks9h-PDxrTYWOh0xEz150-q3gjyGNz9p3qhdqqQUM2A@mail.gmail.com>
In-Reply-To: <20160214165048.GA10219@sigill.intra.peff.net>

On Sun, Feb 14, 2016 at 8:50 AM, Jeff King <peff@peff.net> wrote:

Show 11 quoted lines

> On Sat, Feb 13, 2016 at 05:39:34PM -0800, Shawn Pearce wrote:
>
>> For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the
>> additional text stored in CURLOPT_ERRORBUFFER to debug why
>> the connection did not start. This is curl_errorstr inside
>> of http.c, so include that in the message if it is non-empty.
>
> I think this is an all-around improvement. GitHub sometimes get support
> requests for result=18 on a git-push, which is curl's code for "I dunno,
> the remote end hung up". Having a human-readable message may make things
> less confusing.

I have been trying to recreate the error 35 scenario, but after almost a day of continuous attempts with a suspected broken Git I thus far have not been able to reproduce it. *sigh*

What made me pick this up was I got another recent report of a Debian system having trouble connecting to $DAY_JOB's HTTPS server, which reminded me of [2]. I was going to revive that patch, but instead decided to expand on the error reporting.

[2] http://article.gmane.org/gmane.comp.version-control.git/206770

Show 8 quoted lines

> Unfortunately I cannot seem to create the problem at will to confirm
> that it kicks in in this case[1], but it seems like it should just based on
> reading your patch.
>
> -Peff
>
> [1] I tried inserting "exit(0)" in various places of receive-pack, and
>     it seems make the protocol deadlock. Yikes.

This actually doesn't surprise me. *sigh*

With all the pipes and libcurl in there, we must somewhere be ignoring the fact that the HTTP server closed the connection.