- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Fri, 24 Jul 1998 11:10:07 -0400
- To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>
- Cc: John Stracke <francis@netscape.com>, w3c-dist-auth@w3.org
Thanks for the information about Apache. The new collections requirements draft has new text related to direct references. We've stayed with the direct / indirect terminology because internal / external already has a different meaning attached to it in WebDAV: Here are the definitions: Direct Reference A reference that has the property that operations on it are passed through to its target Indirect Reference A reference that has the property that operations on it do not affect its target Some rationale: Similarly, both indirect and direct references may be useful. Each of these types of references is implemented in existing systems. Existing HTTP servers are capable of supporting both types of references. In effect, indirect references give clients access to the reference itself, and allow the reference to bear properties. Direct references, once created, simplify access to the target resource by hiding from clients the fact that there is a reference mediating between the client and the target resource. Although it is desirable for WebDAV to support both indirect and direct references, the difficulties of supporting direct references make it unlikely that they will be supported in the short term. And 3 new requirements that explain how direct references differ from indirect references. 3.1.15 Operations on a direct reference, except for creation and deletion of the reference itself, are passed through to its target resource. This requirement is really a restatement of the definition of a direct reference. There are several reasons for wanting to support this sort of resource. Direct references simplify operations for clients, hiding from them the fact that a reference is mediating between their requests and the target resource. Many existing systems, including HTTP servers, implement direct references. Supporting direct references does introduce issues that make it unlikely that WebDAV will support them in the short term. Passing operations through to the target resource exposes servers to the risks of circular references and long chains of references that refer to other references. In addition, passing operations through to the target resource can be problematic if the referential resource and the target resource are on different servers. Issues about what credentials to use would need to be addressed. 3.1.16 For any resource, it is possible to discover whether it is a direct reference. Since the behavior of direct references is radically different from the behavior of indirect references, it is important for clients to be able to discover whether they are operating on a direct reference. The client must have a way of finding out whether the properties it sets will be stored on the reference or on its target, etc. 3.1.17 It is not possible for a client to set or view properties of a direct reference, distinct from those of its target. Again, this follows from the definition of a direct reference. Since all operations except creating the reference and deleting the reference are passed through to the target, the client can operate only on properties of the target. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu] > Sent: Thursday, July 23, 1998 5:16 AM > To: slein@wrc.xerox.com > Cc: John Stracke; w3c-dist-auth@w3.org > Subject: Re: Direct and Indirect References > > > I can describe what Apache already does using configuration files, > which won't go away even after WebDAV is implemented. I'd like to > have all three forms of names (direct, indirect, and actual) available > for manipulation via WebDAV. > > The goal of a direct reference (what Apache terms an internal > redirect) > is to provide the same source at multiple names in the namespace. > The most frequent use of this is for content negotiation, > where a request > on a basename automatically creates a mapping to all other names in > that directory with the same basename. Likewise, we can do the same > thing with derived content. A less often used purpose, though > more applicable to WebDAV, is to maintain separate resource trees so > that access can be more easily controlled by URL. For example, by > placing all of the writable resources (the source) under one URL tree > and all the read-only handles for those resources under a different > URL tree, it is easier to maintain the ACLs. Of course, this isn't > an ideal way to implement WebDAV for these resources, but it is one > that works on systems where per-URL ACLs are inconvenient. > > Note that this functionality cannot be implemented by external > redirects (indirect references) because the actual destination > resource may be under different access restrictions than the direct > reference handle. > > Regarding terminology, "direct reference" brings to mind a normal URL, > whereas "indirect reference" is using one URL to access > another resource > indirectly (what you are terming a direct reference). Since that is > very confusing, I suggest instead that they be referred to as > externally-redirecting names and internally-redirecting names. > > ....Roy >
Received on Friday, 24 July 1998 11:11:07 UTC