Junio C Hamano wrote:
> + 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
$ git push https://b...@git.crustytoothpaste.net/git/bmc/test.git
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://b...@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
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
Wouldn't a natural fix be to *always* use "Expect: 100-continue" when
and only when the probe_rpc() revealed a server supporting
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html