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

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:

>     +http.continue::
>     +	Ensure that authentication succeeds before sending the pack data when
>     +	POSTing data using the smart HTTP transport.

I think we always do that (since v1.7.5-rc0~82^2~1, "smart-http: Don't
use Expect: 100-Continue", 2011-02-15), in probe_rpc().

This series seems to be instead about ensuring that authentication
succeeds before proceding, within the same connection.  The commit
message doesn't mention this, but the symptom being addressed is the
following:

	$ git push https://bmc@git.crustytoothpaste.net/git/bmc/test.git development
	Counting objects: 37994, done.
	Delta compression using up to 4 threads.
	Compressing objects: 100% (10683/10683), done.
	Writing objects: 100% (37994/37994), 9.15 MiB | 4.45 MiB/s, done.
	Total 37994 (delta 26760), reused 37633 (delta 26467)
	Unable to rewind rpc post data - try increasing http.postBuffer
	Password for 'https://bmc@git.crustytoothpaste.net': 

As Brian explains:

	GSS-Negotiate authentication always requires a rewind with cURL.

While reviewing patch 1/2, this workaround seemed like a good idea to
me --- it lets GSS-Negotiate authentication work without harming
current users.  But after reviewing patch 2/2, it seems that there is
no good value to set this option to (I don't mean no good *default*
value, but no good value at all).  That tells me that either the
documentation needs improvement or this is the wrong knob to make
configurable.

The problem:

 a) If I set "[http] use100Continue" to true, then I can use
    GSS-Negotiate authentication without running into the problem of
    not being able to rewind.  But when I try to use code.google.com
    it will hang for a second while it waits for the 100-continue.

 b) If I set "[http] use100Continue" to false, then I can access
    code.google.com without any 1-second delays.  But I cannot perform
    large pushes using GSS-Negotiate authentication without increasing
    http.postBuffer.

Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
and only when the probe_rpc() revealed a server supporting
GSS-Negotiate authentication?