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

> * 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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to