From: Junio C Hamano <gitster@pobox.com>
To: "Kirill A. Korinskiy" <catap@catap.ru>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] handle_remote_ls_ctx can parsing href starting at http://
Date: Sun, 21 Dec 2008 01:42:42 -0800 [thread overview]
Message-ID: <7vr641rhil.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1229772213-11932-1-git-send-email-catap@catap.ru> (Kirill A. Korinskiy's message of "Sat, 20 Dec 2008 14:23:33 +0300")
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> The program call remote_ls() to get remote objects over http;
> handle_remote_ls_ctx() is used to parse it's response to populated
> "struct remote_ls_ctx" that is returned from remote_ls().
>
> The handle_remote_ls_ctx() function assumed that the server will
> returned local path in href field, but RFC 4918 demand of support full
> URI (http://localhost/repo.git for example).
Do you mean "the client should support both server-relative '/repo.git'
and full 'http://localhost/repo.git'", or "the client should reject
'/repo.git' and insist on full 'http://localhost/repo.git'"? I am
guessing the former but it is not quite clear. Where in 4918 is this
specified?
> This resulted in push failure (git-http-push ask server
> PROPFIND /repo.git/alhost:8080/repo.git/refs/) when a server returned
> full URI.
This is an interesting but confusing example.
Do you mean the bug is:
(1) the client asks PROPFIND /repo.git/;
(2) the server gives http://localhost/repo.git/refs back;
(3) the client incorrectly assumes that the response would start with
/repo.git/ (e.g. "/repo.git/refs"), so strips 10 bytes from the
beginning of this result and uses the remainder as the "new"
information to dig deeper; i.e. "alhost/repo.git/refs";
(4) the new part is appended to the original path and the client forms
the next request "PROPFIND /repo.git/alhost/repo.git/refs/";
(5) instead, the client should strip the proto://host part (if exists)
and request "PROPFIND /repo.git/refs/".
> @@ -1424,9 +1425,10 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
> ls->userFunc(ls);
> }
> } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
> - ls->dentry_name = xmalloc(strlen(ctx->cdata) -
> + char *path = strstr(ctx->cdata, remote->path);
> + ls->dentry_name = xmalloc(strlen(path) -
> remote->path_len + 1);
What if you are talking to http://repo.git/repo.git/? Doesn't this
strstr() misbehave? Instead, shouldn't you be checking if the response
begins with proto://host/ and stripping it iff so?
next prev parent reply other threads:[~2008-12-21 9:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-20 11:23 [PATCH] handle_remote_ls_ctx can parsing href starting at http:// Kirill A. Korinskiy
2008-12-21 9:42 ` Junio C Hamano [this message]
[not found] <7v3aghnv1t.fsf@gitster.siamese.dyndns.org>
2008-12-23 8:31 ` Kirill A. Korinskiy
2008-12-25 7:04 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr641rhil.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=catap@catap.ru \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.