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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

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.

So essentially the question is, do we believe that Negotiate and other
authentication are likely to be used together, and are we willing to
take the risk that a user wants to use non-Negotiate on such a server
and has a broken server or proxy?

> 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.  I think that in practice that's unlikely to be the case, as
most people using GSSAPI authentication probably use Kerberos as their
authentication server, and Digest hashes the password in a different way
that isn't compatible.  I'm the only person I'm aware of, other than
Stanford (and potentially MIT), that uses Kerberos auth over HTTP, and
probably fewer still use it for git push.

I think that this is probably fine to do, because probably most people
who are using Kerberos auth over HTTP are using Apache or nginx, which
support 100-continue, and many of those institutions are universities,
which don't tend to have restrictive (and broken) proxies.  It also is
fine with me because it means that things just work and I don't have to
worry about setting configuration options.

I'll plan to do a revised patch along these lines later this week unless
I hear some loud objections before then.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]