WebDAV Advanced Collections Conference Call - 2/9/99 Attending: Judy Slein, Jim Davis, Tyson Chihaya, Chuck Fay, Jim Whitehead, Geoff Clemm ACTION ITEMS Judy: Spec changes Judy: Update issues list Judy: Write up concern about not responding with 302 to COPY for redirect references NEXT WEEK: Revisit LOCKING, anything else that arises from the versioning workshop. LOGISTICS Cut-off for Internet Drafts is February 26. Judy will aim to submit our draft February 19. Send out a call for volunteers to review the spec in detail when the new draft gets posted on Internet Drafts. COPY (ISSUE 16) Original proposal: COPY by default affects the target. Because the point of doing a COPY is to end up with a separate resource that can be modified without affecting the original resource. Chris Kaler thought that copying the link would be the default behavior -- think about Windows, where an icon indicates the type of resource you are working with. If you copy a shortcut, you expect to get a copy of the shortcut, not a copy of the content it points to. We agree this is not a compelling argument. Windows is a referencing-aware client. The default behavior should be what down-level clients need. Referencing-aware clients can always use No-Passthrough. Jim W: When you copy a tree, you expect the whole tree to behave as the original tree did. This argues that you would copy the references, not copy their targets into the new tree. Geoff: If you are copying a tree to a tape for archive, you want to be sure that you have all the content, not a bunch of broken references. Agreed: We want to be consistent between the case where we COPY an individual reference, the case where we COPY a collection that contains references, and the case where we COPY a reference whose target is a collection. Agreed?: COPY on a direct reference gets passed through to the target. (So similarly for COPY on a collection that contains direct references -- the targets of the direct references get copied into the new collection.) Chuck is not happy about this for direct references in collections -- you want the new collection to behave just like the old -- you want a No-Passthrough header on the new collection to get the same results as on the old. The issues are all related to redirect references: Note that in WebDAV COPY and MOVE are *not* atomic. If a problem is encountered while copying a collection, the server copies as much of the tree as it can. 302 seems intuitive for the top level (request COPY for a redirect reference whose target is a collection), but not inside tree (request COPY for a collection that contains redirect references). If there are redirect references inside the tree, a Multi-Status response with reftype and location for each redirect reference could be returned. The client can then decide whether to do the actual copies. Do we really want to require a Multi-Status response? The client can traverse the tree before COPY to discover whether there are any redirect references. What would WebDAV require for a pre-referencing redirect resource in a collection that is being COPIED? Can we be consistent with that behavior? Proposal: COPY on a redirect always copies the reference itself, and does not return a 302. have direct be transparent have redirect not have that transparency clients encouraged to do propfind if they care, in case there might be redirect involved redir always down-level is ok, when do GET result is redirect What would a COPY on an old-fashioned 302 do? We should do the same for redirect references. WebDAV is silent about COPY on a 302 resource because it expected consulting the HTTP spec would give the right answer. Jim W: if hardcoded 302s, response should be multistatus - COPY and MOVE are best effort. Jim W: (a few minutes later) succeed or 404, never 302 Also waffled on whether a 302 resource would be listed in a PROPFIND on the collection that contains it. Roy thinks it is a resource, and so should be returned in a collection listing. Jim W: Either the server knows that for this URL it should always return 302 to any request, or else there is a simple resource there that always returns 302. Is a resource that responds to some requests with 302 required to respond to all requests with 302? Web server might not be able to honor any new semantics for a 302. Jim D: Server does copy foo.cgi to a place that doesn't support cgi, and reports success even if won't run. [What point is this trying to make? JS] Chuck: In some cases we let redirect references behave like 302 resources. (Geoff: They model (mimic) 302 resources.) If we want to do something different in this case, we need to do it consciously and explain why. Chuck: From perspective of down-level client, where some 302s are from ordinary 302 resources and some are from redirect references, how do the semantics look? Chuck: If we choose a different semantics for redirect references and old 302 resources, ok. But make sure it's not consequential to down-level clients or consciously write them off. Jim W: It won't be a common operation to copy a redirect reference. It will be more common to copy a collection that contains redirect references. If a client copies a collection, it probably wanted redirect references copied. So it's better not to return 302s. Judy: We introduced the 302 response for redirect references (and the name "redirect reference" to go with it) to allow down-level clients to use redirect references. We shouldn't abandon down-level clients if we can help it. Judy: Write up this concern. Should we consider using 307 (Temporary Redirect) (See the latest HTTP draft 06) instead of 302? No, probably very few clients are following new developments in the HTTP spec. SECURITY (ISSUE 10) We should state the Hide-Target concerns, and point out that they can be partially addressed by an ACL mechanism at the level of properties. The Ref-Target header is, however, returned in the response to many requests and can't be hidden by hiding properties. It would be possible to create a ref on a trusted server, pointing to a hacker's server, to make people send information unwittingly to the hacker's server. (For redirect references, see HTTP/1.1 -- client is required to notify the user for requests other that GET or HEAD.) If a direct reference has a target on a different server, there are performance and security issues. In the previous case, if a hacker compromises a trusted server using direct references, there will be no indication to the user that the operation is going off server (unless the client watches for reftype / reftarget in response). Remove 2.6 Modifications of Ordering. This is not a serious risk. Add to 12.2 Denial of Service that there are already other ways to mount denial of service attacks -- posting the URL on a Web page at a busy site. HIERARCHIES OF REFERENCES (ISSUE 19) Jim W: Agree on the semantics we think are right without worrying about consistency with the WebDAV spec. We'll revisit the WebDAV spec's statements about namespace consistency on the way to draft standard, and take into account the referencing semantics. Consider the URL /x/y.html, where /x/ is a reference whose target is collection /a/. Then y.html is a member of /a/. y.html may also be a reference. Since /x/ is a reference, it can't have members. So you dereference it and see whether it points to a collection. If not, a request on the URL /x/y.html fails. If so, then you check that collection to see whether it has a member y.html. If not, a request on the URL fails. There is no significant performance issue associated with this semantics if there is a mapping from DAV references to operating system constructs (Unix symbolic links, Windows shortcuts).