Jeff King <peff@xxxxxxxx> writes:
> Most of the time, this is not a big deal; for both fetching
> and pushing, we make a GET request before doing any POSTs,
> so typically we figure out the credentials during the first
> request, then reuse them during the POST. However, some
> servers may allow a client to get the list of refs from
> receive-pack without authentication, and then require
> authentication when the client actually tries to POST the
> pack.
A silly question. Does the initial GET request when we push look
any different from the initial GET request when we fetch? Can we
make them look different in an updated client, so that the server
side can say "this GET is about pushing into us, and we require
authentication"?
> Unfortunately, it is not as easy as simply calling post_rpc
> again when it fails, due to the input issue mentioned above.
> However, we can still make this specific case work by
> retrying in two specific instances:
>
> 1. If the request is large (bigger than LARGE_PACKET_MAX),
> we will first send a probe request with a single flush
> packet. Since this request is static, we can freely
> retry it.
>
> 2. If the request is small and we are not using gzip, then
> we have the whole thing in-core, and we can freely
> retry.
>
> That means we will not retry in some instances, including:
>
> 1. If we are using gzip. However, we only do so when
> calling git-upload-pack, so it does not apply to
> pushes.
>
> 2. If we have a large request, the probe succeeds, but
> then the real POST wants authentication. This is an
> extremely unlikely configuration and not worth worrying
> about.
>
> While it might be nice to cover those instances, doing so
> would be significantly more complex for very little
> real-world gain. In the long run, we will be much better off
> when curl learns to internally handle authentication as a
> callback, and we can cleanly handle all cases that way.
I suspect that in real life, almost nobody runs smart HTTP server
that allows anonymous push.
How much usability penalty would it be if we always fill credential
before pushing? Alternatively, how much latency penalty would it
incur if we always send a probe request regardless of the request
size when we try to push without having an authentication material?
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> Sorry for the wordy explanation. I really tried to refactor this into a
> nice single code path for making both GET and POST requests, but I think
> there are just too many corner cases. Suggestions welcome if somebody
> has a better idea of how to refactor it (preferably in the form of a
> patch).
>
> remote-curl.c | 23 +++++++++++++++--------
> t/t5541-http-push.sh | 2 +-
> 2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index 04a9d62..3ec474f 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -362,16 +362,17 @@ static size_t rpc_in(char *ptr, size_t eltsize,
>
> static int run_slot(struct active_request_slot *slot)
> {
> - int err = 0;
> + int err;
> 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);
> + err = handle_curl_result(slot);
> + if (err != HTTP_OK && err != HTTP_REAUTH) {
> + error("RPC failed; result=%d, HTTP code = %ld",
> + results.curl_result, results.http_code);
> }
>
> return err;
> @@ -436,9 +437,11 @@ static int post_rpc(struct rpc_state *rpc)
> }
>
> if (large_request) {
> - err = probe_rpc(rpc);
> - if (err)
> - return err;
> + do {
> + err = probe_rpc(rpc);
> + } while (err == HTTP_REAUTH);
> + if (err != HTTP_OK)
> + return -1;
> }
>
> slot = get_active_slot();
> @@ -525,7 +528,11 @@ static int post_rpc(struct rpc_state *rpc)
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
>
> - err = run_slot(slot);
> + do {
> + err = run_slot(slot);
> + } while (err == HTTP_REAUTH && !large_request && !use_gzip);
> + if (err != HTTP_OK)
> + err = -1;
>
> curl_slist_free_all(headers);
> free(gzip_body);
> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
> index 9b1cd60..ef6d6b6 100755
> --- a/t/t5541-http-push.sh
> +++ b/t/t5541-http-push.sh
> @@ -280,7 +280,7 @@ test_expect_success 'push over smart http with auth' '
> test_cmp expect actual
> '
>
> -test_expect_failure 'push to auth-only-for-push repo' '
> +test_expect_success 'push to auth-only-for-push repo' '
> cd "$ROOT_PATH/test_repo_clone" &&
> echo push-half-auth >expect &&
> test_commit push-half-auth &&
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html