smart-http: Don't use Expect: 100-Continue
authorShawn O. Pearce <spearce@spearce.org>
Tue, 15 Feb 2011 16:57:24 +0000 (08:57 -0800)
committerJunio C Hamano <gitster@pobox.com>
Tue, 15 Feb 2011 19:42:20 +0000 (11:42 -0800)
commit206b099d269955337bd6169f71aa08ba28a0cf4f
tree24e37ceee6da5cda5ece85db69f75a41fcf1a9c6
parent547e8b9205349b47003ed25a82673e413e71c255
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>
remote-curl.c