WebDAV Collections Breakout Session December 8, 1998 Judy Slein jslein@crt.xerox.com

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

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

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

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

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

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

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

WebDAV Advanced Collections Other Issues . . . WebDAV Advanced Collections