don't append 'opaquelocktoken:' in PUT and MOVE

In 753bc91 ("Remove the requirement opaquelocktoken uri scheme"), the lock token is guaranteed to be prefixed with the string 'opaquelocktoken:', which propagated down to file path creation operations in the remote repository, namely, in start_put (and consequently start_move).

These file operations may not be successful, due to the colon ':' character in the file path (specifically, in Windows).

This patch ensures that the lock token sans 'opaquelocktoken:' is used instead in start_put.

Note on tests: In the second grep, we check that Apache returns status 20* (ie. the request was successful), but in the first we do not do so, since file creation by PUSH/MOVE is not guaranteed to succeed (see above).

---

 http-push.c          |    2 +-
 t/t5540-http-push.sh |    9 +++++++++
 2 files changed, 10 insertions(+), 1 deletions(-)

index eefd64c..10df94a 100644
@@ -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, request->lock->token + 16);
 	request->url = strbuf_detach(&buf, NULL);
 
 	slot = get_active_slot();

index c236b5e..544dea8 100755
@@ -94,6 +94,15 @@ test_expect_success 'MKCOL sends directory names with trailing slashes' '
 
 '
 
+test_expect_success 'PUT and MOVE sends object to URLs without "opaquelocktoken:"' '
+
+	!(grep -P "\"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_opaquelocktoken:[\da-z\-]{36} HTTP/[0-9.]+\"" \
+	< "$HTTPD_ROOT_PATH"/access.log) &&
+	grep -P "\"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_[\da-z\-]{36} HTTP/[0-9.]+\" 20\d" \
+	< "$HTTPD_ROOT_PATH"/access.log
+
+'
+
 stop_httpd
 
 test_done

1.6.1.2.278.g9a9e.dirty

I am not familiar with DAV so I have to wonder who guarantees in the codepath that the string that follows the "opaquelocktoken:" (and any other lock token uri scheme) is without problematic characters, such as a slash (or colon)?

Hi,

Hi,

Any solutions for this? Would a comment like "skip 'opaquelocktoken:' prefix of length 16" be sufficient? Or maybe in the commit message?

I considered a set of strbuf functions, like for the remote object url (get_remote_object_url and append_remote_object_url), but I thought it was a little overkill, since this is one of the only instances that I can think of where including 'opaquelocktoken:' is unwanted.

Are you suggesting perhaps that we revert commit 753bc91? Or perhaps create another way to access lock tokens, say, get_lock_token(int prepend_scheme)?

Cheers,
Ray Chuan

Hi,

I do not suggest anything like that.

But I _refuse_ to go and investigate a thing that you should know already, and that you should be able to defend, indeed, something you should have defended in the commit message:

Why does request->lock->token have the prefix at all?

Ciao,
Dscho

Hi,

While typing my reply, I realise it is unwarranted.

Thanks for taking the time to look through this.

Cheers,
Ray Chuan

Hi,

Huh? What does that mean? Does lock->token have that prefix (including the colon) or not?

Ciao,
Dscho

Hi,

Yes, it does have the prefix with colon, but it is not true that it is always "opaquelocktoken:" -- it could be some other URI scheme.

I submitting a new patch that accounts for this (other URI schemes).

Cheers,
Ray Chuan