Re: [PATCH v2 2/2] Update documentation for http.continue option
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Oct 23, 2013, 03:21 UTC
- Message-ID
- <CAJo=hJssxNtJSeLgwG5nON=Y-7HzZPULiwzH+0SXeU8tp3FC-A@mail.gmail.com>
- In-Reply-To
- <20131023030048.GX865149@vauxhall.crustytoothpaste.net>
On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:
Show 11 quoted lines
> 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.
Show 9 quoted lines
>> 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.