Slide 7 of 9
Notes:
Ref-Type and Ref-Target are always included in a response to a request on a dangling reference. Their presence indicates that it’s the target, not the reference, that is Not Found. (If the reference itself were not found, these headers wouldn’t be available.)
Exsception: If the reference was created with Hide-Target, the Ref-Target header is not returned.
PUT, MKCOL, MKREF don’t care whether there is a resource at Ref-Target. If there is a resource there, they over-write it (except for MKCOL, which fails); if there is no resource there, they create a new resource at Ref-Target.
DELETE, MOVE, COPY always affect the reference itself, so they don’t care whether there is anything at Ref-Target. If the reference is broken at the old location for MOVE, COPY, then it will also be broken at the new location.
PROPFIND, PROPPATCH always get a Multi-Status response??? Within the 207, the dangling reference gets a 404.
If LOCK, UNLOCK is being applied to a collection that has a dangling reference as a member, the response is a 409 with a multistatus element in the entity body (as required by the WebDAV spec), including a 404 for the dangling reference.
If LOCK, UNLOCK is being applied just to a dangling reference, the response is a 404.