After the authenticated request, curl says it's keeping the connection open, but the next fetch seems to do two handshakes again. The unauthenticated request closes the connection, so the 2nd handshake is forced, but I'm not sure why subsequent git fetches still do handshakes. I did a bit of sleuthing w/ source, GIT_CURL_VERBOSE and wireshark. We're using GitHub enterprise -- it'd just be nice if there was a better way to configure for super fast fetches. ssh with cached connections does avoid the SSL this overhead -- though as I recall git protocols over ssh are less performant. Finally I also checked out the persistent-https contrib section as a workaround but couldn't get it to work. Is that project dead? Thank you for your replies and support. Regards, Isaac On Thu, Apr 14, 2016 at 5:46 AM, Daniel Stenberg <daniel@xxxxxxx> wrote: > On Wed, 13 Apr 2016, Jeff King wrote: > >> However, I don't think even that would give you what you want. Because I >> think that even if we provide a credential, curl will make an initial >> request (presumably to find out which auth type it should use, but that >> is just a guess). I don't know if there is a way to convince curl to >> stick the credential in the first request > > > curl supports this. but then you must do exactly that: tell libcurl to use > that single auth method only. It will of course make it fail if you select > the wrong method etc. > > The unauthenticated first request is both to probe for which methods the > server wants, but also works for the case when users provide credentials > without the server actually ending up asking for them... > > -- > > / daniel.haxx.se -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html