On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. Yes. >> 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, etc. -- 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