On Wed, Feb 22, 2017 at 01:25:11PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I don't think it incurs an extra round-trip now, because of the way > > libcurl works. Though I think it _does_ make it harder for curl to later > > optimize out that extra round-trip. > > ... > > In the current trace, you can see that libcurl insists on making a > > second auth-less request after we've fed it credentials. I'm not sure > > how to get rid of this useless extra round-trip, but it would be nice to > > do so (IIRC, it is a probe request to find out the list of auth types > > that the server supports, which are not remembered from the previous > > request). > > ... > > With http.emptyauth, the second round-trip _isn't_ useless. It's trying > > to send the empty credential. > > > > So while curl isn't currently optimizing out the second call, I think > > http.emptyauth makes it harder to do the right thing. > > ... > > I think that would keep it to 2 round-trips for the normal "Basic" case, > > as well as for the GSSNegotiate case. It would be 3 requests when the > > server offers GSSNegotiate but you can't use it (but you could set > > http.emptyauth=false to optimize that out). > > Thanks for your thoughts. I'd think that we should take this change > and leave the optimization for later, then. It's not like the > change of the default is making the normal situation any worse, it > seems. I'm not excited that it will start making known bogus-username requests by default to servers which do not even support Negotiate. I guess that is really the server-operators problem, but it feels pretty hacky. -Peff