"However, there is absolutely no reason to validate lock tokens on a COPY source because the source is
not being modified."
Actually, there is a *very* good reason to do so. Consider the scenario: I lock A/B. Then I copy A to C,
presenting the lock token for A/B. The semantics of this operation is, "make the copy, conditioned
upon the fact that $token is found." Or to put another way, "nobody has modified A/B, which is critical
when I copy it to C." ... there is a valid scenario where after the lock of A/B, another client
administratively unlocks it, and modifies it. Thus, jeopardizing what gets copied to C/B.
To put another way, "preconditions" include *both* ETags and lock tokens. Operations can be
conditioned upon either datum.
"DAV specifically says you should not do this."
Citation? I don't recall this within the DAV spec.
I concur that this situation could be improved with an API change between mod_dav and its backend.
We felt that was out of scope, and would require an update of both httpd *and* svn to acquire a fix for
this issue. ... And yes, it is true that we might not remember to fix this, if mod_dav decides to change
the behavior (which I doubt).
"if the destination of the COPY already exists, we need to check the locks."
Hmm? We don't allow overwrites. The destination should never exist (the FS will throw an error if it
does). mod_dav *does* attempt to check for a lock on the parent dir (the list of members is being
modified), but we do not have locks on directories, so that's a null operation.