http-push: refactor request url creation

PATCH In review Tay Ray Chuan 3 participants 4 messages Jun 15, 2016

Share & tools

Tay Ray Chuan

author

2016-06-15 22:46 UTC #0 lore raw

PATCH 1/1 http-push: refactor request url creation

Currently, functions that deal with objects on the remote repository have to allocate and do strcpys to generate the URL.

This patch saves them this trouble, by providing two functions, "append_remote_object_url" and "get_remote_object_url".

Both generate a URL, with either the object's 2-digit hex directory (eg. /objects/a1/), or the complete object location (eg. /objects/a1/b2).

However, they differ in that "append_remote_object_url" appends this URL to a strbuf, while "get_remote_object_url" wraps around the former and returns the URL directly in char*. Users usually would use "get_remote_object_url", but may find "append_remote_object_url" useful if they require further string operations on the URL.

PS. In "start_fetch_loose", the variable "url" which is passed to "curl_easy_setopt" is removed, and in its place "request->url" is used. This is safe, since curl strdup's it.

Signed-off-by Tay Ray Chuan <[email protected]>

Acked-by Johannes Schindelin <[email protected]>

Acked-by Junio C Hamano <[email protected]>

---

* renamed only_two_digit_postfix in original patch to only_two_digit_prefix
* rebased and generated on master (5dc1308)
* updated with Junio's changes (if (...) and fix memory leak)
* updated with Junio's double interface
* rebased and generated on master (297f6a5)

 http-push.c |   64 +++++++++++++++++++++++-----------------------------------
 1 files changed, 25 insertions(+), 39 deletions(-)

http-push.c +25 ~~-39~~

index 59037df..6511d19 100644
@@ -209,6 +209,20 @@ static struct curl_slist *get_dav_token_headers(struct remote_lock *lock, enum d
 	return dav_headers;
 }
 
+static void append_remote_object_url(struct strbuf *buf, const char *url, const char *hex, int only_two_digit_prefix)
+{
+	strbuf_addf(buf, "%sobjects/%.*s/", url, 2, hex);
+	if (!only_two_digit_prefix)
+		strbuf_addf(buf, "%s", hex+2);
+}
+
+static char *get_remote_object_url(const char *url, const char *hex, int only_two_digit_prefix)
+{
+	struct strbuf buf = STRBUF_INIT;
+	append_remote_object_url(&buf, url, hex, only_two_digit_prefix);
+	return strbuf_detach(&buf, NULL);
+}
+
 static void finish_request(struct transfer_request *request);
 static void release_request(struct transfer_request *request);

@@ -254,8 +268,6 @@ static void start_fetch_loose(struct transfer_request *request)
 	char *hex = sha1_to_hex(request->obj->sha1);
 	char *filename;
 	char prevfile[PATH_MAX];
-	char *url;
-	char *posn;
 	int prevlocal;
 	unsigned char prev_buf[PREV_BUF_SIZE];
 	ssize_t prev_read = 0;

@@ -305,17 +317,7 @@ static void start_fetch_loose(struct transfer_request *request)
 
 	git_SHA1_Init(&request->c);
 
-	url = xmalloc(strlen(remote->url) + 50);
-	request->url = xmalloc(strlen(remote->url) + 50);
-	strcpy(url, remote->url);
-	posn = url + strlen(remote->url);
-	strcpy(posn, "objects/");
-	posn += 8;
-	memcpy(posn, hex, 2);
-	posn += 2;
-	*(posn++) = '/';
-	strcpy(posn, hex + 2);
-	strcpy(request->url, url);
+	request->url = get_remote_object_url(remote->url, hex, 0);
 
 	/* If a previous temp file is present, process what was already
 	   fetched. */

@@ -359,7 +361,7 @@ static void start_fetch_loose(struct transfer_request *request)
 	curl_easy_setopt(slot->curl, CURLOPT_FILE, request);
 	curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
 	curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, request->errorstr);
-	curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+	curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
 	curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_pragma_header);
 
 	/* If we have successfully processed data from a previous fetch

@@ -388,16 +390,8 @@ static void start_mkcol(struct transfer_request *request)
 {
 	char *hex = sha1_to_hex(request->obj->sha1);
 	struct active_request_slot *slot;
-	char *posn;
 
-	request->url = xmalloc(strlen(remote->url) + 13);
-	strcpy(request->url, remote->url);
-	posn = request->url + strlen(remote->url);
-	strcpy(posn, "objects/");
-	posn += 8;
-	memcpy(posn, hex, 2);
-	posn += 2;
-	strcpy(posn, "/");
+	request->url = get_remote_object_url(remote->url, hex, 1);
 
 	slot = get_active_slot();
 	slot->callback_func = process_response;

@@ -512,7 +506,7 @@ static void start_put(struct transfer_request *request)
 {
 	char *hex = sha1_to_hex(request->obj->sha1);
 	struct active_request_slot *slot;
-	char *posn;
+	struct strbuf buf = STRBUF_INIT;
 	enum object_type type;
 	char hdr[50];
 	void *unpacked;

@@ -551,21 +545,13 @@ static void start_put(struct transfer_request *request)
 
 	request->buffer.buf.len = stream.total_out;
 
-	request->url = xmalloc(strlen(remote->url) +
-			       strlen(request->lock->token) + 51);
-	strcpy(request->url, remote->url);
-	posn = request->url + strlen(remote->url);
-	strcpy(posn, "objects/");
-	posn += 8;
-	memcpy(posn, hex, 2);
-	posn += 2;
-	*(posn++) = '/';
-	strcpy(posn, hex + 2);
-	request->dest = xmalloc(strlen(request->url) + 14);
-	sprintf(request->dest, "Destination: %s", request->url);
-	posn += 38;
-	*(posn++) = '_';
-	strcpy(posn, request->lock->token);
+	strbuf_addstr(&buf, "Destination: ");
+	append_remote_object_url(&buf, remote->url, hex, 0);
+	request->dest = strbuf_detach(&buf, NULL);
+
+	append_remote_object_url(&buf, remote->url, hex, 0);
+	strbuf_addstr(&buf, request->lock->token);
+	request->url = strbuf_detach(&buf, NULL);
 
 	slot = get_active_slot();
 	slot->callback_func = process_response;

Signature · 1 line

1.6.1.1.251.g0dfa1

Junio C Hamano

2016-06-15 22:46 UTC #1 lore raw

Quoted 6 lines · Tay Ray Chuan

Currently, functions that deal with objects on the remote repository have to allocate and do strcpys to generate the URL.
This patch saves them this trouble, by providing two functions, "append_remote_object_url" and "get_remote_object_url".
Both generate a URL, with either the object's 2-digit hex directory (eg. /objects/a1/), or the complete object location (eg. /objects/a1/b2).

Quoted 7 lines

However, they differ in that "append_remote_object_url" appends this URL to a strbuf, while "get_remote_object_url" wraps around the former and returns the URL directly in char*. Users usually would use "get_remote_object_url", but may find "append_remote_object_url" useful if they require further string operations on the URL.
PS. In "start_fetch_loose", the variable "url" which is passed to "curl_easy_setopt" is removed, and in its place "request->url" is used. This is safe, since curl strdup's it.
Signed-off-by Tay Ray Chuan <[email protected]>
Acked-by Johannes Schindelin <[email protected]>
Acked-by Junio C Hamano <[email protected]>

What's with these loooooooooooooooooooooooooooooong lines?

I thought at least you did not have these overlong lines in your earlier attempts, and Dscho may have acked one of those, but I doubt he would give his Ack to this one. I certainly wouldn't Ack it myself.

By the way, aren't you sending format="flowed"? Please don't. It damages whitespaces.

Daniel Stenberg did a research on the safety of your "since curl stdrup's it" claim, and found that it unsafe for earlier versions of the library before 7.17.0.

It seems that we earlier found out that anything older than 7.16 were not usable for git-http-push (see Release Notes for 1.5.4), but 7.16 is still older than 7.17, so either we declare you _must_ have 7.17 or newer to use http-push, or keep an extra copy around and free it later like the original code does.

Even Debian is at 7.18.2 these days, so requiring 7.17 or newer may not be an issue in practice, but there are people who keep running things on older distros with proven stability (and known features limitation).

The refactoring looked sane otherwise, but I think we would want to opt for safety by keeping an extra string around.

Thanks.

Johannes Schindelin

2016-06-15 22:46 UTC #2 lore raw

Hi,

Quoted 3 lines · Junio C Hamano

I thought at least you did not have these overlong lines in your earlier attempts, and Dscho may have acked one of those, but I doubt he would give his Ack to this one. I certainly wouldn't Ack it myself.

My understanding is that the ACK is sent to the mailing list by the Acker and in response to the particular patch she is Acking.

Quoted 2 lines

The refactoring looked sane otherwise, but I think we would want to opt for safety by keeping an extra string around.

Yep. Better safe 'n sorry.

Ciao,
Dscho

Tay Ray Chuan

author

2016-06-15 22:46 UTC #3 lore raw

In reply to Tay Ray Chuan

Hi,

Quoted 8 lines · Junio C Hamano

What's with these loooooooooooooooooooooooooooooong lines?
I thought at least you did not have these overlong lines in your earlier attempts, and Dscho may have acked one of those, but I doubt he would give his Ack to this one. I certainly wouldn't Ack it myself.
By the way, aren't you sending format="flowed"? Please don't. It damages whitespaces.

I used Thunderbird since Gmail kept wrapping lines in the patch, guess i"ll have to manually wrap the commit lines.

Quoted 10 lines

Daniel Stenberg did a research on the safety of your "since curl stdrup's it" claim, and found that it unsafe for earlier versions of the library before 7.17.0.
It seems that we earlier found out that anything older than 7.16 were not usable for git-http-push (see Release Notes for 1.5.4), but 7.16 is still older than 7.17, so either we declare you _must_ have 7.17 or newer to use http-push, or keep an extra copy around and free it later like the original code does.

Quoted 6 lines

Even Debian is at 7.18.2 these days, so requiring 7.17 or newer may not be an issue in practice, but there are people who keep running things on older distros with proven stability (and known features limitation).
The refactoring looked sane otherwise, but I think we would want to opt for safety by keeping an extra string around.

Hmm, since that string won't be released in start_fetch_loose, or anywhere else, would this be considered a memory leak?

Signature · 2 lines

Cheers,
Ray Chuan