Golang webdav COPY lock about litmus HOT 3 CLOSED

thank you, now it's clear

from litmus.

I think this is fairly clear in the RFC, e.g. in RFC 4918 https://www.rfc-editor.org/rfc/rfc4918#section-7

   Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH,
   LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and
   MKCOL are affected by write locks.  All other HTTP/WebDAV methods
   defined so far -- GET in particular -- function independently of a
   write lock.

thus a write lock does not affect the source resource of a COPY. So it is reasonable for litmus to test that behaviour. Does that make sense?

FWIW I agree with the comment, it might be racy, but a user-agent could use a Depth: 1 or Depth: infinity lock on the collection if required to avoid such races.

from litmus.

This specific case is also used an example in https://www.rfc-editor.org/rfc/rfc4918#section-7.5.1

from litmus.