[+cc Daniel for curl questions below] On Wed, Apr 03, 2013 at 12:43:02PM +0300, Mikko Rapeli wrote: > Maybe my git installation was incomplete before when running from ~/bin since > I was not able to set break points to http_request() and some debug code > was not there until I ran git through bin-wrappers in the source tree. Debugging git-over-http is somewhat difficult because the interesting bits happen in sub-processes. You can get much closer to the http calls by running the transport helper directly, like: gdb --args git-remote-https https://yourhost/ which will start by reading commands from stdin (try "list" to get it to fetch the remote refs). > I added some debug prints to http.c functions http_request() and > handle_curl_result(), and now I see this chain of events: > > http_request_reauth() > http_request() > GET ...info/refs?service=git-upload-pack > HTTP/1.1 401 Authorization Required > * Ignoring the response-body > * Issue another request to this URL: '...' > GET ...info/refs?service=git-upload-pack > HTTP/1.1 401 Authorization Required > handle_curl_result: res = 22, http_code = 401, user = ..., pass = (null) > Password for '...': (enter valid password) > GET ...info/refs?service=git-upload-pack > HTTP/1.1 200 OK > > So, for some reason the first GET request is issued twice and first 401 > is ignored. I'll try to debug run_active_slot() next... Right, I think that's curl trying to make use of the username in the URL. Try this (I'm using github here as a convenient http servers, but you should be able to replicate with your internal server): $ GIT_CURL_VERBOSE=1 git ls-remote https://foo@xxxxxxxxxx/requires/auth \ 2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL' > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 < HTTP/1.1 401 Authorization Required > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOg== < HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 Password for 'https://foo@xxxxxxxxxx': > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOmJhcg== < HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 So you can see that curl makes _two_ requests internally before it returns the 401. One unadorned, and one with just the username ("Zm9vOg==", which decodes to "foo:") for the auth. Then git prompts for the password, and we retry (and of course I am feeding it a bogus username/password combo, so we get another 401). I would expect without the username in the URL for it to make only two requests: one to get the first 401, then git collects the credentials, then a follow-up with the credentials. But instead we get: $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \ 2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL' > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 * The requested URL returned error: 401 Authorization Required Username for 'https://github.com': foo Password for 'https://foo@xxxxxxxxxx': > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 < HTTP/1.1 401 Authorization Required > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOmJhcg== < HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 So we get a 401, as expected, git prompts for the credentials and feeds them directly to curl, but then we still get _two_ requests: we trigger another 401, and only then does curl provide the authorization header to the server. I'm not sure if that extra auth is intended or not. It's also possible that git is screwing up in providing the credentials to curl, but I don't think so. We feed them to the curl handle as soon as we get them, and there should be only one handle in use here. -Peff -- 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