Dangling direct references
GET, HEAD, POST, OPTIONS
- 404 (Not Found), Ref-Type, Ref-Target
PUT, MKCOL, MKREF, DELETE, MOVE, COPY
PROPFIND, PROPPATCH
- 207 (Multi-Status)
- For the dangling reference: 404, Ref-Type, Ref-Target
LOCK/UNLOCK
- 409 (Conflict) if reference is in a collection that is being LOCKED or UNLOCKED
- 404 if direct reference is being LOCKED or UNLOCKED
- Include Ref-Type, Ref-Target
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.