Subject: Re: remaining redirect ref issues

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Nov 2003 15:29:49 +0100

Hi,

in case people want to discuss this during the IETF meeting, here's a 
summary of the major open issue left with the redirect references 
protocol 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>).

There are (at least) two major design goals, but unfortunately both are 
in direct contradiction:

#1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any 
request that addresses a redirect reference resource MUST result in a 
3xx status code (obviously the whole point is that GET MUST result in a 
redirection, and if it does, it's hard to say why other methods such as 
PUT or DELETE should behave differently). Therefore, the redirect 
reference protocol introduces a new request header 
("Apply-To-Redirect-Ref") through which a client can indicate that the 
request indeed should be applied to the redirect reference resource itself.

#2: Maximum usability with existing clients. For instance, the Microsoft 
Webfolder client will not be able to DELETE a redirect reference 
resource unless the server deviates from #1.

Right now I'm not sure about the best way to resolve this. Currently the 
spec chooses #1 (back when this decision was made, there was probably 
the assumption that existing clients would quickly be updated -- 
something that probably isn't true today).

However this may result in implementers either just ignoring these 
rules, or adding special workarounds based on "User Agent" detection.

Feedback appreciated,

Julian

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Nov 2003 13:08:34 -0800

> There are (at least) two major design goals, but unfortunately both 
> are in direct contradiction:
>
> 3xx status code (obviously the whole point is that GET MUST result in 
> a redirection, and if it does, it's hard to say why other methods such 
> as PUT or DELETE should behave differently). Therefore, the redirect 
> #2: Maximum usability with existing clients. For instance, the 
> Microsoft Webfolder client will not be able to DELETE a redirect 
> reference resource unless the server deviates from #1.
>
> Right now I'm not sure about the best way to resolve this. Currently 
> the spec chooses #1 (back when this decision was made, there was 
> probably the assumption that existing clients would quickly be updated 
> -- something that probably isn't true today).

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.

....Roy

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 18 Nov 2003 18:53:32 -0800

In principle, I agree with Roy on this issue.

But a problem with the "authoring URI" approach occurs when you want to
apply a Depth operation (e.g. PROPFIND).  You can get all the authoring
URIs with a single Depth PROPFIND, but then how do you avoid having to
apply the operation separately to each of the authoring URIs?

In the case of PROPFIND, there is a solution provided by RFC-3253
(the DAV:expand-property REPORT), but that only works for PROPFIND,
not for other Depth methods like COPY.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Nov 2003 12:12:08 +0100

Roy T. Fielding wrote:

> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get straight
> an XML document -- that is what must be defined by the redirect protocol.

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 20 Nov 2003 09:30:25 -0500

Below I expressed a general problem with the "authoring URI" approach
and Depth operations.  In this particular case (i.e. redirect reference
resources), there is the additional problem that I can't use PROPFIND
to find out the "authoring URI" (because the redirect reference will
automatically redirect the PROPFIND request away from the redirect 
resource).
So I'd need to define a GET-REDIRECT-AUTHORING-URI method to find out
the authoring URI (and then have the problem described in my original
message :-).  The header approach is looking better and better (:-).

Cheers,
Geoff