x/net/webdav: delete should release locks #42839
Open
Labels
Milestone
Comments
Seems overlooked by triage? |
klarose
added a commit
to Agilicus/golang-net
that referenced
this issue
Jan 21, 2021
The WebDAV RFC indicates that locks rooted on deleted resource MUST be destroyed. The WebDAV server does not do this with the builtin in-memory lock system (memLS). This commit adds a new interface, implemented by memLS, which allows for deleting locks rooted at a given resource. We added a new interface rather than extending or changing the existing one to avoid breaking backwards compatibility with other implementations of the LockSystem interface. The WebDAV server will behave as it used to if using a LockSystem which has not implemented the new interface. We apply the same operation for moved files. This follows from the WebDAV RFC which indicates that a move is logically a copy followed by consitency checks, followed by a delete of the source. Fixes golang/go#42839
I have a potential fix for this. Going to wait for my CLA to go through, but feel free to take a look. |
Change https://golang.org/cl/285753 mentions this issue: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
I haven't tried yet, but the relevant code does not seem to have changed.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I'm using https://github.com/hacdias/webdav to evaluate a few things. I plan on implementing my own server using the webdav library soon, but wanted to get some testing done on it before diving in. While testing (using davfs2 as a client), I noticed that if I did the following, the third operation would always fail.
The requests/responses issued by davfs2/returned by webdav are:
If I wait for a bit between when I create the file and delete it, everything works fine. It looks to me like davfs2 creates the lock, but does not flush the contents of the file/release the lock until some time expires. If I remove the file before that time expires, davfs2 issues the DELETE without releasing the lock. The problem is that despite the file not existing, the webdav server still thinks that a lock is present for the file, so it refuses to lock it again in step 5.
Perhaps davfs2 should release the lock. But, the webdav RFC is pretty clear that the lock should be released when the file is deleted:
Detailed reproduction steps:
cadaver http://localhost:8080
423 Locked
. It should have succeeded.What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: