Re: [PATCH] use lock token in non-URI form in start_put
From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:07
Hi, On Sun, 8 Feb 2009, Tay Ray Chuan wrote:
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"),
lock tokens are in the URI forms in which they are received from the
server, eg. 'opaquelocktoken:', 'uuid:'
However, "start_put" (and consequently "start_move"), which attempts to
create a unique temporary file using the UUID of the lock token,
inadvertently uses the lock token in its URI form. These file
operations on the server may not be successful (specifically, in
Windows), due to the colon ':' character from the URI form of the lock
token in the file path.If it is a prefix that happens to be part of the URI, but must not be used by the client code as a lock token, would it not be better to store the token in lock->token to begin with?
quoted hunk ↗ jump to hunk
To do this, the "start_put" gets the position of ':', which is used to separate the URI scheme from the part, eg. "<scheme>:". In addition, start_put uses the last position of ':', since URIs with component URIs are possible, eg. "urn:uuid:" One can be sure that the lock token will always contain the UUID and be in URI form, due to RFC 2518, or its successor RFC 4918 (see http://www.webdav.org/specs/rfc4918.html#ELEMENT_locktoken). Signed-off-by: Tay Ray Chuan <redacted> Signed-off-by: Tay Ray Chuan <redacted> --- http-push.c | 2 +- t/t5540-http-push.sh | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletions(-)diff --git a/http-push.c b/http-push.c index eefd64c..bd8f372 100644 --- a/http-push.c +++ b/http-push.c@@ -558,7 +558,7 @@ static void start_put(struct transfer_request *request) append_remote_object_url(&buf, remote->url, hex, 0); strbuf_addstr(&buf, "_"); - strbuf_addstr(&buf, request->lock->token); + strbuf_addstr(&buf, strrchr(request->lock->token, ':') + 1);
This is unsafe. What if lock->token does not contain a colon? Even if it happens to be the case now, in your setup, it might change, or there might be mistakes in the server code. We should always play it safe if we cannot control the other side's code. Ciao, Dscho