x/net/webdav: moving a locked file fails unless destination is locked #43556
What version of Go are you using (
The text was updated successfully, but these errors were encountered:
Some follow up thoughts/comments:
My findings imply that you can only move a source to a locked destination, which is not correct. The locked resource should simply be renamed, with the lock discarded as per the webdav RFC:
From inspecting the code, it looks like the lock subsystem takes an optional src/dst parameter. If both are set, it tries to take locks on both resources. If only one is set, it takes only that one. In none are set, it takes temporary locks to maintain locking consistency with other clients.
In the move handler, since there is a src and dst, it looks for locks in both places, even if dst is not present or unlocked:
So, even though we've only locked src, and dst doesn't exist, the request will fail because we don't have a valid lock on dst.
Really, the check should be "if there is no condition for a given resource, take a temporary lock on it", rather than "if there are no conditions, take a temporary lock on all".
If there's interest, I can look at implementing something to fix this (as well as #42839). Both issues are currently blocking us, so we need a solution soon (i.e. the next few weeks). I can look at putting up a PR with the fix. I wouldn't mind some guidance from those experienced with this codebase, particularly for this issue, since I think the fix may not be as simple as #42839.
The WebDAV RFC is pretty clear that if the source and destination of a MOVE request are locked, then the request must include lock tokens for both. It doesn't explicitly state that if only one is locked, the request need only include a token for the one, but that seems fairly obvious: if the destination of an operation is not locked, a client should be able to copy or move a locked resource over top of it, particularly if it doesn't exist in the first place. Prior to this commit, the lock validation logic required that both the source and destination of an operation hold a lock if any locks were presented. Consequently, binary operations where only one of the resources were locked would always fail. For example, the following sequence of events would fail with a 412 Precondition Failed: - LOCK /foo - MOVE /foo (Destination: /bar) This commit changes the lock validation to only require locks for resources which are actually locked. It takes some care to ensure that invalid lock tokens will cause a failure, even if the resources did not require locks, since both the litmus test and RFC imply that if there are any conditions, and all conditions fail, the request should fail. Fixes golang/go#43556