Re: [PATCH] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Sep 21, 2012, 14:19 UTC
- Message-ID
- <CAJo=hJs=Zm4BPm94-sNWDUNkg2vAReSsTmKnDVw+xOU9NWcfUQ@mail.gmail.com>
- In-Reply-To
- <20120921052606.GA9659@sigill.intra.peff.net>
On Thu, Sep 20, 2012 at 10:26 PM, Jeff King <peff@peff.net> wrote:
Show 15 quoted lines
> On Thu, Sep 20, 2012 at 04:05:03PM -0700, Shawn O. Pearce wrote: > >> But right now I am seeing failures in libcurl's SSL connection that >> may also be causing the smart connection failures. For example this >> trace, where libcurl was just not able to connect to respond to the >> 401 with a password. I suspect what is happening is the SSL session >> dropped out of cache on our servers, and libcurl couldn't reuse the >> existing SSL session. Instead of discarding the bad session and >> retrying, Git aborts. I'm willing to bet modern browsers just discard >> the bad session and start a new one, because clients can't assume the >> remote server will be able to remember their session forever. > > That's something I haven't seen. But then, I don't usually see the > client side; I just see the fallback dumb fetch in our logs, and > have occasionally followed up.
I hadn't seen this either until I deleted the fallback code from remote-curl.c and ran git ls-remote in a while true loop for 6 hours. Its obviously happening though.
> Is there a long pause while the user is typing their password?
No. The password comes off a credential helper that has access to it from a credential store. There is very little lag here, under 100 ms.
Show 15 quoted lines
>> * SSL re-using session ID >> * Unknown SSL protocol error in connection to android.googlesource.com:443 >> * Expire cleared >> * Closing connection #0 >> error: Unknown SSL protocol error in connection to >> android.googlesource.com:443 while accessing >> https://android.googlesource.com/a/platform/tools/build/info/refs?service=git-upload-pack >> fatal: HTTP request failed > > You could try turning off CURLOPT_SSL_SESSIONID_CACHE and seeing if that > improves it. Of course, it is probably hard to reproduce, so it would be > tough to know if that helped or not. It would also be nice if you could > dump more information on the error from the ssl library (I typically > build curl against openssl; I wonder if it could be related to using > gnutls or something).
This is OpenSSL, because I also always build against OpenSSL. :-)
I'll try the CURLOPT_SSL_SESSIONID_CACHE today. It is hard to reproduce, so not producing it doesn't necessarily mean it isn't still there.