Re: Cannot clone the git repository shared over http with authorization.

From: Jeff King <peff@peff.net>
Date: Apr 2, 2012, 08:31 UTC
Message-ID: <20120402083115.GA2235@sigill.intra.peff.net>
In-Reply-To: <20120401194534.GA16512@ecki>

On Sun, Apr 01, 2012 at 09:45:36PM +0200, Clemens Buchacher wrote:

Show 5 quoted lines

> So far I figured out that setting 'git config http.maxRequests 1' fixes
> the problem as well. Looking at the output with GIT_CURL_VERBOSE=1 set,
> it seems that some GET requests use the credentials, while others do
> not. My guess is that the CURLOPT_USERPWD option does not apply to all
> threads.

Yes, that is exactly it. Furthermore, the multi-fetch code paths used by the http walker do not have the magic "notice a 401 and retry". I think something like this should fix it (it passes your tests):

diff --git a/http.c b/http.c
index f3f83d7..c6dc9b7 100644
--- a/http.c
+++ b/http.c
@@ -494,6 +494,8 @@ struct active_request_slot *get_active_slot(void)
 	curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);
 	curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
 	curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
+	if (http_auth.password)
+		init_curl_http_auth(slot->curl);
 
 	return slot;
 }

which is basically just double-checking that we set CURLOPT_USERPWD
whenever we get a slot (I wish there was some way of asking "does this
curl handle have USERPWD already set?", but I couldn't fine one).

It still doesn't do 401-handling itself, but it works OK in practice
because the first request will be a non-multi fetch (to get info/refs),
which recognizes the 401 and prompts the user, and then that credential
gets used subsequently.

-Peff