aboutsummaryrefslogtreecommitdiff
path: root/tar.h
diff options
context:
space:
mode:
authorShawn O. Pearce <spearce@spearce.org>2011-02-15 08:57:24 -0800
committerJunio C Hamano <gitster@pobox.com>2011-02-15 11:42:20 -0800
commit206b099d269955337bd6169f71aa08ba28a0cf4f (patch)
tree24e37ceee6da5cda5ece85db69f75a41fcf1a9c6 /tar.h
parent547e8b9205349b47003ed25a82673e413e71c255 (diff)
downloadgit-206b099d269955337bd6169f71aa08ba28a0cf4f.tar.gz
git-206b099d269955337bd6169f71aa08ba28a0cf4f.tar.xz
smart-http: Don't use Expect: 100-Continue
Some HTTP/1.1 servers or proxies don't correctly implement the 100-Continue feature of HTTP/1.1. Its a difficult feature to implement right, and isn't commonly used by browsers, so many developers may not even be aware that their server (or proxy) doesn't honor it. Within the smart HTTP protocol for Git we only use this newer "Expect: 100-Continue" feature to probe for missing authentication before uploading a large payload like a pack file during push. If authentication is necessary, we expect the server to send the 401 Not Authorized response before the bulk data transfer starts, thus saving the client bandwidth during the retry. A different method to probe for working authentication is to send an empty command list (that is just "0000") to $URL/git-receive-pack. or $URL/git-upload-pack. All versions of both receive-pack and upload-pack since the introduction of smart HTTP in Git 1.6.6 cleanly accept just a flush-pkt under --stateless-rpc mode, and exit with success. If HTTP level authentication is successful, the backend will return an empty response, but with HTTP status code 200. This enables the client to continue with the transfer. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'tar.h')
0 files changed, 0 insertions, 0 deletions