On Sat, May 10, 2014 at 09:01:32PM +0000, brian m. carlson wrote:
> What it looks like is happening is that git is offering Negotiate data,
> and then your server is responding with a 401 Unauthorized. libgit2
> (presumably using WinHTTP) continues in this case, retrying with a
> longer set of credential containing more data, but git gives up.
>
> Both responses comply with RFC 2616, by my reading. I guess there are a
> couple of choices here:
>
> * Make your web server happy with the data that it gets passed
> initially.
> * Make git understand that it really needs to try again with different
> credentials in this case (how to do that is unknown).
It should be pretty straightforward to loop again; http_request_reauth
just needs to turn into a for-loop on getting HTTP_REAUTH, rather than a
static two-tries (I even had a patch for this a while ago, but the
function has changed a bit in the interim).
The tricky part is figuring out when to return HTTP_NOAUTH ("do not try
again, we failed") versus HTTP_REAUTH ("get credentials and try again")
in handle_curl_result. Right now the decision is based on "did we have a
username and password for this request?" I'm not clear on what extra
bits would be needed to decide to continue in the case you guys are
discussing.
> * Provide some way of forcing git to use a particular authentication
> protocol.
Yeah, we just set CURLAUTH_ANY now, but it would be fairly trivial to
add "http.authtype" and "http.proxyauthtype" to map to CURLOPT_HTTPAUTH
and CURLOPT_PROXYAUTH.
-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