Re: [PATCH v2 2/2] Update documentation for http.continue option

[Shawn Pearce <spearce@spearce.org>]

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