threads / patch / 17420

patchhttp-push: refactor request url creation

Subject: [PATCH] http-push: refactor request url creation

## tl;dr

4 messages between Jan 28, 2009 and Jan 29, 2009. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Tay Ray Chuan· Jan 28, 2009, 22:19 UTC · lore
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 <rctay89@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <gitster@pobox.com>
---
* 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(-)
Show changes to http-push.c +25 −39
diff --git a/http-push.c b/http-push.c
index 59037df..6511d19 100644
--- a/http-push.c
+++ b/http-push.c
@@ -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;
-- 
1.6.1.1.251.g0dfa1
Junio C Hamano· Jan 28, 2009, 22:51 UTC · re: Tay Ray Chuan · lore

Re: [PATCH] http-push: refactor request url creation

Tay Ray Chuan <rctay89@gmail.com> writes:
Show 13 quoted lines
> 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 <rctay89@gmail.com>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Acked-by: Junio C Hamano <gitster@pobox.com>
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· Jan 28, 2009, 23:06 UTC · re: Junio C Hamano · lore

Re: [PATCH] http-push: refactor request url creation

Hi,
On Wed, 28 Jan 2009, Junio C Hamano wrote:
> 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.

> 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· Jan 29, 2009, 11:49 UTC · re: Tay Ray Chuan · lore

Re: [PATCH] http-push: refactor request url creation

Hi,
On Thu, Jan 29, 2009 at 6:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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.

Show 16 quoted 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.
>
> 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?

-- 
Cheers,
Ray Chuan

← back to recent threads