1. March 17, 1999 Judy Slein jslein@crt.xerox.com
WebDAV Collections
March 17, 1999
Judy Slein

2. WebDAV Advanced Collections
Reference Types
Redirect
Simple for servers to implement, never requires proxy behavior from server
Requires client action before it can be resolved
Client is aware of mediating reference
Direct
Server resolves automatically
Client has the illusion that it is operating directly on the target resource
WebDAV Advanced Collections

3. Default Referencing Behavior: Rules of Thumb
Methods on Redirect References
302 response, Location header gives URI of target
Client either resubmits to target or resubmits to reference with No-Passthrough
Methods on Direct References
Automatically passed through to target
Generally, we’d like the default behavior to be what makes most sense for a down-level client, because a down-level client can’t get any other behavior than this. (Sometimes other considerations forced us to compromise this aim.)
There is always a way for a reference-aware client to get the non-default behavior. (In most cases, by using the No-Passthrough header, which causes the method to be applied to the reference.)
WebDAV Advanced Collections

4. Default Referencing Behavior: 4 Cases
Redirect References
Collections That Contain Redirect References
Direct References
Collections That Contain Direct References
For each method, we have to define default behavior for these 4 cases.
So far, we NEVER violate this rule: the default behavior for a reference is the same as the default behavior when a reference is encountered while processing a method for a collection.
WebDAV Advanced Collections

5. WebDAV Advanced Collections
No-Passthrough
No-Passthrough prevents the request from being passed through to the target resource
WebDAV Advanced Collections

6. Referencing Behavior: Principles
References should be usable by down-level clients
Default behavior should be what makes sense to down-level clients
Always be consistent between individual references and references encountered when processing a collection
Never require a server to resolve a redirect reference
Be consistent across operations as far as possible
Be consistent with WebDAV and HTTP semantics for operations they define
These principles often conflict, so we have to make tradeoffs.
WebDAV Advanced Collections

7. Default Referencing Behavior
There are the easy cases, where we follow the rule of thumb for default behavior.
WebDAV Advanced Collections

8. Default Referencing Behavior
These are the difficult cases, where we felt we had to deviate from the rule of thumb. We’ll look at these in detail on the next slides.
WebDAV Advanced Collections

9. WebDAV Advanced Collections
MOVE and DELETE
Default: Apply to reference
Apply to target by sending request to the URI in the DAV:reftarget property
Rationale:
MOVE and DELETE affect membership in collections, not individual resources
Should affect only the collection where the reference resides
Should not affect the membership of the collection where the target resides
Should not affect other collections that contain references to the target
If a reference-aware client REALLY wants to apply the method to the target, it can do so by looking up the target’s URI in the DAV:reftarget property, and submitting the request to it.
Other rationale:
This is the way file systems behave.
Passing MOVE and DELETE through to targets can do very widespread damage (much more so than other methods that affect only individual resources). They can result in every reference to the moved or deleted resource being broken, and if applied to a collection, then every reference to every member of the collection might be broken.
WebDAV Advanced Collections

10. WebDAV Advanced Collections
COPY
Expect COPY to create a new, independent resource that can be modified without affecting the original resource
Default: COPY on direct reference applies to target
The right result
Default: COPY on redirect reference applies to reference
Intuitively wrong
Avoids 302 responses when operating on a collection
There is no way to get 302 response
What a client expects may be different for collections than for individual resources. When copying a collection that contains references, do you expect to end up with a collection that behaves like the original (e.g.., gives 302s where the original collection did) or one that has copies of all the targets of the references, so that they can be operated on independently of their source?
Is the size of the resulting collection an issue? Of course, it would be larger if targets are copied in.
Remember that a reference-aware client can get the behavior it wants in any case. The issue is, what should the default behavior be.
It seems unfortunate that the spec treats direct and redirect references differently: for direct references, it applies to the target, for redirect it applies to the reference. If you have a collection with both direct and redirect references, this seems pretty weird.
Appeal to precedent doesn’t help, since NT copies the reference but Unix copies the target.
Take the site administrator’s point of view: Are there operations that we would like to PREVENT down-level clients from performing?
If you let COPY apply to the reference, you have to worry about fixing up relative URIs in DAV:reftarget. (You have to do this in either the non-default case or the default case anyhow.)
WebDAV Advanced Collections

11. WebDAV Advanced Collections
LOCK / UNLOCK
Need lock on both reference and target to prevent surprises
Default: LOCK on direct reference locks target
Rules of good citizenship prevent surprise changes to reference
Consistent with typical behavior of methods on direct references
Default: LOCK on redirect reference locks reference
Avoids 302 responses when operating on a collection
302 would make it impossible to lock collections that contain redirect references
Even if you lock both the reference and its target, you can’t prevent all surprises. If there is a reference embedded in the URL, you would have to lock that, too. But then you would be preventing anyone from working in that collection, an unacceptable situation especially for configuration management. So since we can’t prevent surprises, let’s do what’s consistent with most other default behavior: pass the LOCK request through to the target.
There’s a debate about what ref 2518 requires -- what would we have to say to be consistent with it?
In versioning: The resource that a reference points to is determined not just by the reference, but by a computation on the reference + Workspace or Revision-Name header. Locking the reference in this situation would not give the right result.
Geoff: Do you want to say we should NEVER allow the reference to be locked? We should forbid No-Passthrough on a LOCK request?
For redirects, revisit the question whether it’s ok to prevent any LOCKing of collections that contain redirect references. That would be the effect of having 302 responses. Yaron seems to think this is ok.
WebDAV Advanced Collections

12. Other Referencing Issues
YG-7 References to Collections
YG-8, YG-11 Ref-Type and Ref-Target in Responses
Instead of No-Passthrough, use a different URL for the reference
If a server creates a reference to a collection, is it also required to create a reference to each member of the collection? No: what collection would these references belong to? There is no good candidate. Besides, the server can parse and resolve URIs that contain the collection reference without having a reference to the collection members.
Should we require Ref-Type and Ref-Target to be returned in responses to COPY and LOCK requests? Or to any requests? The problems arise when operating on collections. Then you need to add reftype and reftarget to multistatus responses. This means extending rfc 2518’s syntax, but worse, may actually break some down-level clients. (They will expect an empty response body for a successful COPY. They will expect a prop response, not a multistatus response, for a successful LOCK.)
Alternatives to No-Passthrough:
A DAV:ref property like the DAV:source property, that a client can use if it wants to apply a request to the reference
A DAV:config property that the client can use to edit the config file to change where methods are directed
WebDAV Advanced Collections