summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 547e8b9)
raw | patch | inline | side by side (parent: 547e8b9)
author | Shawn O. Pearce <spearce@spearce.org> | |
Tue, 15 Feb 2011 16:57:24 +0000 (08:57 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Tue, 15 Feb 2011 19:42:20 +0000 (11:42 -0800) |
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>
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 | patch | blob | history |
diff --git a/remote-curl.c b/remote-curl.c
index d38812085151b6738e7ca95be10968b973bf13b4..256326afb5c720bf7451e227c838701d4fd75d0c 100644 (file)
--- a/remote-curl.c
+++ b/remote-curl.c
return size;
}
+static int run_slot(struct active_request_slot *slot)
+{
+ int err = 0;
+ struct slot_results results;
+
+ slot->results = &results;
+ slot->curl_result = curl_easy_perform(slot->curl);
+ finish_active_slot(slot);
+
+ if (results.curl_result != CURLE_OK) {
+ err |= error("RPC failed; result=%d, HTTP code = %ld",
+ results.curl_result, results.http_code);
+ }
+
+ return err;
+}
+
+static int probe_rpc(struct rpc_state *rpc)
+{
+ struct active_request_slot *slot;
+ struct curl_slist *headers = NULL;
+ struct strbuf buf = STRBUF_INIT;
+ int err;
+
+ slot = get_active_slot();
+
+ headers = curl_slist_append(headers, rpc->hdr_content_type);
+ headers = curl_slist_append(headers, rpc->hdr_accept);
+
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, rpc->service_url);
+ curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "");
+ curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, "0000");
+ curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDSIZE, 4);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &buf);
+
+ err = run_slot(slot);
+
+ curl_slist_free_all(headers);
+ strbuf_release(&buf);
+ return err;
+}
+
static int post_rpc(struct rpc_state *rpc)
{
struct active_request_slot *slot;
- struct slot_results results;
struct curl_slist *headers = NULL;
int use_gzip = rpc->gzip_request;
char *gzip_body = NULL;
- int err = 0, large_request = 0;
+ int err, large_request = 0;
/* Try to load the entire request, if we can fit it into the
* allocated buffer space we can use HTTP/1.0 and avoid the
rpc->len += n;
}
+ if (large_request) {
+ err = probe_rpc(rpc);
+ if (err)
+ return err;
+ }
+
slot = get_active_slot();
- slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
/* The request body is large and the size cannot be predicted.
* We must use chunked encoding to send it.
*/
- headers = curl_slist_append(headers, "Expect: 100-continue");
+ headers = curl_slist_append(headers, "Expect:");
headers = curl_slist_append(headers, "Transfer-Encoding: chunked");
rpc->initial_buffer = 1;
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
- slot->curl_result = curl_easy_perform(slot->curl);
- finish_active_slot(slot);
-
- if (results.curl_result != CURLE_OK) {
- err |= error("RPC failed; result=%d, HTTP code = %ld",
- results.curl_result, results.http_code);
- }
+ err = run_slot(slot);
curl_slist_free_all(headers);
free(gzip_body);