- 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