1. WebDAV Collections Breakout Session
December 8, 1998
Judy Slein

2. WebDAV Advanced Collections
Issues
Behavior of direct references
Headers
More on headers
Status codes
Dangling direct references
Chains of direct references
Other Issues . . .
WebDAV Advanced Collections

3. Behavior of Direct References
All methods get passed through to target except
DELETE
MOVE
COPY
Rationale for this list
References allow access to resources from multiple collections. Clients can build new collections be referencing existing resources.
Direct references make it look to the client as if it is directly accessing the resource.
Want to accomplish this without interfering with anyone else’s view of the world, any other collections that reference the resource.
So we’ll pass through every operation except DELETE, MOVE
We’ve also included COPY on the list of operations not passed through, but the same rationale doesn’t apply to it.
Can we provide a different rationale, or do we want to drop it from the list?
WebDAV Advanced Collections

4. WebDAV Advanced Collections
Headers
1. Every response to a request on a reference MUST include Ref-Type
2. Every response to a request on a direct reference MUST include Ref-Target
3. Every (successful) response to a GET or HEAD request on a redirect reference MUST include Ref-Type, Ref-Target, and Ref-Integrity
1. So that a referencing-aware client can tell whether it was operating on a reference, and whether the operation was (by default) applied to the reference or to its target. This can be helpful especially in case of a 3xx or 4xx response, or to let the client know that it must resolve a redirect reference in order to do anything useful.
2. Exceptions: if the reference was created with Hide-Target, or if the current request included Re-Direct.
So that the client can tell what resource was affected by its request.
3. Follows the general rule for GET and HEAD, that responses MUST include all entity headers for the resource
WebDAV Advanced Collections

5. WebDAV Advanced Collections
More on Headers
Which of the MKREF headers can also be used with
MOVE
COPY
LOCK
Ref-Type
Ref-Target
Ref-Integrity
Hide-Target
Do we need a Resource-Type header?
MOVE and COPY:
Can you change Ref-Type, Ref-Target, Ref-Integrity, Hide-Target at the new location? The current spec says you can change Ref-Type, Ref-Target, Ref-Integrity. Hide-Target is not addressed.
Can you change Resource-Type on a MOVE or COPY?
[WebDAV] Section 7.4 allows you to LOCK a null resource and then perform a PUT or MKCOL on it. So it seems as if you should also be able to perform a MKREF on it. A lock-null resource has no value for DAV:resourcetype? It gets a resource type when PUT, MKCOL, or MKREF is performed on it. All the MKREF headers get applied only with the MKREF request, not the LOCK.
Aside: Do we need a DAV:hidetarget property? If we want clients to be able to change whether a reference’s target is hidden after the reference has been created, we either have to provide such a property or have clients submit another MKREF request (in effect replace the existing reference with a new one) with the Hide-Target header present or absent.
WebDAV Advanced Collections

6. WebDAV Advanced Collections
Status codes
409 (Conflict)
where the conflict is not with the state of the resource, but with some other resource
207 (Multi-Status)
where the method allows multiple elements in a single request, but the client only included a single element
where a single reason explains why none of the elements in the request could be satisfied
409: For example, the request tries to position the resource in an ordering before or after a resource that is not in the collection. So the conflict is with the state of the collection, not with the state of the resource identified by the request-URI. Or the request might try to position a resource in an unordered collection.
207: For example, on an ORDERPATCH where only a single change is requested, the behavior should be analogous with PROPPATCH where only a single change to a single property is requested -- must it be a 207?
For example, a PROPFIND or PROPPATCH on a dangling direct reference. Must the response be 207 (Multi-Status), or could it just be a 404 (Not Found)?
WebDAV Advanced Collections

7. Dangling direct references
GET, HEAD, POST, OPTIONS
404 (Not Found), Ref-Type, Ref-Target
PUT, MKCOL, MKREF, DELETE, MOVE, COPY
succeed
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
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.
WebDAV Advanced Collections

8. Chains of direct references
How can a chain of direct references be created?
Dangling direct references
What happens if a reference in the middle of a chain gets deleted?
Which Ref-Target gets returned in responses?
How can I see the properties of an intermediate reference in the chain? Or perform any other operation on an intermediate reference in the chain?
1. If you do a MKREF with Ref-Target = dref1, does DAV:reftarget get set to dref1 or to its target?
You can replace an ordinary target resource with a direct reference.
2. Dangling References: the Ref-Target that gets included in the 404 response is the URI of the resource that is missing. So if a direct reference in the middle of a chain gets deleted, its URI gets returned as the missing Ref-Target.
But what about the methods that the spec claims succeed: PUT, MKCOL, MKREF? They would end up replacing the missing reference, not the resource at the end of the chain. They have no way of knowing the missing resource was itself a reference.
3. The URI of the final target resource, unless one of the references in a chain is broken?
4. There is no way in the current spec.
WebDAV Advanced Collections

9. WebDAV Advanced Collections
Other Issues . . .
WebDAV Advanced Collections