Re: remaining redirect ref issues

Roy T. Fielding wrote:

> I am certain I have said this before, though it was several years ago.
> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get straight
> on that one bit is what causes webdav to trip over HTTP whenever it
> tries to "author" anything other than a boring old file.
> 
> In this case, there must be two different URIs -- one for the resource
> and one for the configuration of that resource.  That configuration
> may be as simple as a URI, maybe a status code and a URI, or maybe even
> an XML document -- that is what must be defined by the redirect protocol.
> The actual URI which responds to requests with a redirect should have a
> link to its configuration URI, such that an authoring tool can discover
> the authorable resource that causes this resource to redirect.  That is
> why webdav requires a source link in order to perform HTTP authoring.
> 
> The same principle holds for all dynamic content.

Well, although I think I agree that this approach would work, it really 
doesn't help resolving the issue we have.

Let's start with a real-world example.

Take a WebDAV collection served by Apache/mod_dav, called "/a", 
containing one internal member "b".

A PROPFIND with Depth: 1 applied to /a will result in a multistatus with 
response elements for

/a
/a/b

Now the admin of the server decides to move the resource, and instead to 
add a permanent redirect reference using httpd.conf. Now, from WebDAV's 
point of view, "/a/b" is gone (because it isn't a WebDAV compliant 
resource anymore).

So PROPFIND Depth: 1 only lists

/a

However a GET on /a/b will return 3xx, so what we have here is a 
non-WebDAV-compliant source in a WebDAV collection. This per se isn't a 
problem.

Now, one of the requirements for the redirect ref spec is to *make* that 
resource WebDAV compliant, thus

- to define how WebDAV methods such as PROPFIND behave,
- to define how they appear as children of their parent collection and
- to define how namespace operations on collections behave if those 
contain redirect references.

Note that these questions are completely independant of how new 
redirects are *authored*.

If I understand you correctly, redirects not being exposed by WebDAV is 
fine and is no problem at all. From that point of view, we indeed don't 
need large parts of the redirect spec at all. However, in our use case 
(a content management system that has link resources), we definitively 
*want* these redirects to be subject of namespace operations.

I also hear that people want to be able to round-trip symbolic links 
between Unix filesystems and a WebDAV store, and redirect resources seem 
to be an obvious mapping.


Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 20 November 2003 06:12:36 UTC