On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson
> On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
>> Forgive my ignorance: is there a way to do something analagous to that
>> patch but for GSS-Negotiate authentication? In other words, after
>> using the first request to figure out what authentication mechanism
>> the server prefers, could git prefer it in remaining requests to avoid
>> the need to rewind?
> We know what authentication mechanisms the server offers, but we don't
> know what curl will use, other than the fact that it prefers non-Basic
> authentication (this is documented). So if we see Negotiate only or
> Negotiate and Basic, we know it will try to use Negotiate if possible.
>> I don't see any simple way to do that using the libcurl API. If
>> checking if the server accepts GSS-Negotiate authentication and using
>> that to decide whether to 'Expect: 100-Continue' is easier, that would
>> be fine, too.
> If that's what the consensus is, that's much, much easier to do. The
> only problem is that if we have Negotiate and a non-Basic method, such
> as Digest, we might force Expect: 100-continue on when it does not need
> to be used.
>From my perspective, it is OK to defaulting to use 100-continue if the
server supports Negotiate. If the user is stuck behind a broken proxy
and can't authenticate, they can't authenticate. They can either set
the variable to false, or fix their proxy, or use a different server,
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