W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

Properties of References

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Wed, 16 Dec 1998 11:29:54 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D32@x-wb-0128-nt8.wrc.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
One of the topics discussed at Orlando -- both in the collections breakout
session and in the WebDAV working group meeting -- was how to allow clients
to access the properties of references.

Based on those discussions, I propose to make the following changes to the
collections specification:

1.  Change the behavior of redirect references so that WebDAV methods (not
just the old HTTP methods) get 302 responses.  (There will still be some
exceptions -- DELETE, MOVE, and COPY always get applied to the reference.)
This makes it possible for non-referencing WebDAV clients to use references.

2.  Replace the Re-Direct header with a No-Passthrough header that can be
applied to any reference, direct or redirect.  This header asks the server
to apply the request to the reference itself, rather than to its target
resource.

Here's the background, for anyone who cares:

As the spec is currently written, accessing the properties of a reference is
a problem only for direct references.  A PROPFIND applied to a redirect
reference will return the properties of the reference, but applied to a
direct reference it will return the properties of the target resource.  (The
Re-Direct header in the current spec addresses this problem for direct
references.)  However, the discussions have made it clear to me that the
spec is inconsistent in its treatment of redirect references.  Once it is
made consistent, the same problem will arise for redirect references.  Let
me explain.

The earliest draft of the collection spec had a very trivial implementation
of indirect (now redirect) references.  They were simply resources that had
no content, and had a DAV:reftarget property that contained the URI of the
target resource.  To use an indirect reference, a client retrieved the value
of DAV:reftarget, and submitted whatever request it liked to that URI.  Any
method that had the reference's own URI as the request-URI would be applied
to the reference itself, not to its target.

At the Redmond meeting, people pointed out that it is important for plain
HTTP clients to be able to use references, even though they don't understand
what references are.  As a result, the spec was revised to require that
servers respond to *HTTP* methods on indirect references with a 302 (Moved
Temporarily) and the reftarget URI in the Location header.  This is the
origin of the new name for these references: redirect references.  

However, the spec still says that *WebDAV* methods applied to redirect
references behave as in the original spec.  They do not get a 302 response,
but rather get applied to the reference itself.  This is inconsistent and
has the consequence that non-referencing WebDAV clients cannot use redirect
references.  The spec needs to change so that any non-referencing client can
use redirect references to get to their targets.  Any method that a
non-referencing client might use should get a 302 response.  (The exceptions
will be DELETE, MOVE, and COPY, which get applied to the reference itself.)

Once this change is made, the problem of how to get / set properties on the
reference itself will be the same for both redirect and direct references.
So there needs to be a header that applies to both.  No-Passthrough seems
like a reasonable name for this header, which means that the server should
not pass the method through to the target resource, but should instead apply
it to the reference.  Although the immediate motivation for this header has
to do with accessing properties, it seems generally useful to be able to
apply *any* method to the reference.  The No-Passthrough header can be used
with any method on a reference.

--Judy

Judith A. Slein
CR&T/ADSTC
jslein@crt.xerox.com
8*222-5169
Received on Wednesday, 16 December 1998 11:25:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:48 GMT