summaryrefslogtreecommitdiff
path: root/t/t7103-reset-bare.sh
diff options
context:
space:
mode:
authorMartin Storsjö <martin@martin.st>2009-12-01 10:33:39 (GMT)
committerJunio C Hamano <gitster@pobox.com>2009-12-01 22:15:27 (GMT)
commit6c81a9908206799ccbc9a17bde17f1d766a8eef4 (patch)
treee1580dfcc89ee7100c5bd4df41b916dce5b5a9b8 /t/t7103-reset-bare.sh
parentb8ac923010484908d8426cb8ded5ad7e8c21a7f6 (diff)
downloadgit-6c81a9908206799ccbc9a17bde17f1d766a8eef4.zip
git-6c81a9908206799ccbc9a17bde17f1d766a8eef4.tar.gz
git-6c81a9908206799ccbc9a17bde17f1d766a8eef4.tar.bz2
Allow curl to rewind the RPC read buffer
When using multi-pass authentication methods, the curl library may need to rewind the read buffers used for providing data to HTTP POST, if data has been output before a 401 error is received. This is needed only when the first request (when the multi-pass authentication method isn't initialized and hasn't received its challenge yet) for a certain curl session is a chunked HTTP POST. As long as the current rpc read buffer is the first one, we're able to rewind without need for additional buffering. The curl library currently starts sending data without waiting for a response to the Expect: 100-continue header, due to a bug in curl that exists up to curl version 7.19.7. If the HTTP server doesn't handle Expect: 100-continue headers properly (e.g. Lighttpd), the library has to start sending data without knowing if the request will be successfully authenticated. In this case, this rewinding solution is not sufficient - the whole request will be sent before the 401 error is received. Signed-off-by: Martin Storsjo <martin@martin.st> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t7103-reset-bare.sh')
0 files changed, 0 insertions, 0 deletions