W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2005

Re: WGLC draft-ietf-webdav-redirectref-protocol-12

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 03 Jul 2005 20:08:31 +0200
Message-ID: <42C8299F.2060805@gmx.de>
To: John Baumgarten <jbaumgarten@apple.com>
CC: WebDav <w3c-dist-auth@w3.org>

John Baumgarten wrote:
> 
> All-
> 
> After reviewing this draft, I have decided that the protocol is too  
> complex for our needs with .Mac.  In particular, the failure of  locking 
> methods that contain redirected resources would confuse our  clients.  
> Instead, we have decided to implement a simpler redirect  capability via 
> a custom property (not a WebDAV resource type) that is  only activated 
> when indicated by the client request.
> 
> Given this decision, I will not be able to provide specific feedback  on 
> the draft.
> 
> -Jake

Jake,

thanks for the feedback.

As a general comment: it's really good to know why a given part of a 
specification can't be easily implemented in a server. That's exactly 
the kind of valuable feedback the working group needs to gather in WGLC 
(or earlier :-).

In this particular case, you have catched a part of the spec which is 
indeed hard to implement (and in fact isn't by us!).

In defining how redirect reference resources should interact with other 
methods and WebDAV collections, the spec roughly follows this line of 
reasoning:

1) HEAD and GET applied to a redirect resource by a standard client 
should result in a 3xx status code (that's the whole point of having 
those resources :-).

2) If this is true for GET and HEAD, it also should be true for other 
methods.

3) Clients aware of REDIRECT should be able to override this behaviour 
(so that they can for instance PROPFIND/PROPPATCH/DELETE a redirect). 
This is accomplished through the use of the Apply-To-Redirect-Ref 
request header (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-12.html#header.apply-to-redirect-ref>).

4) RFC2518 dictates that by default a Depth: infinity request header 
should work as if the request would have been applied to each member; 
therefor REDIRECT requires these operations to result in a 207 
(Multistatus) if the collection contains redirects (and the 
Apply-To-Redirect-Ref wasn't set to "T").

It turns out that 4) is extremly hard to implement on top of systems 
that do not implement any specific treatment of redirects natively.

For instance, an imaginary WebDAV server that maps file resources to 
WebDAV resources and that implements redirects as symbolic links in the 
filesystem would need to walk through the whole hierarchy to check for 
redirects, before actually doing the appropriate system call for a 
rename. This doesn't look practical.

I assume that REDIRECT uses this approach for the sake of maximum 
consistency with HTTP/1.1 (redirect status codes) and WebDAV (Depth 
request header). However, there obviously is a tradeoff in terms of 
implementability. We probably need to take a look at each method that 
uses the Depth request header and decide what is reasonable.

What you stumbled upon was LOCK.

 From RFC2518's definition of the Depth header 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Depth>):

"The Depth header is used with methods executed on resources which could 
potentially have internal members to indicate whether the method is to 
be applied only to the resource ("Depth: 0"), to the resource and its 
immediate children, ("Depth: 1"), or the resource and all its progeny 
("Depth: infinity").

The Depth header is only supported if a method's definition explicitly 
provides for such support.

The following rules are the default behavior for any method that 
supports the Depth header. A method may override these defaults by 
defining different behavior in its definition."

So by this definition, a LOCK request with Depth: Infinity means that 
the request is to be applied to the resource identified by the 
request-URI and - recursively - all its members. This is clearly *not* 
what a deep lock does - it generates a *single* lock, not one for each 
member. This lock indeed affects all members, but in a completely 
different way from what would happen if one would apply the lock to each 
resource separately.

Funny enough, the definition of LOCK indeed clarifies what the Depth 
header means 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4>) here:

"The Depth header may be used with the LOCK method. Values other than 0 
or infinity MUST NOT be used with the Depth header on a LOCK method. All 
resources that support the LOCK method MUST support the Depth header.

A Depth header of value 0 means to just lock the resource specified by 
the Request-URI.

If the Depth header is set to infinity then the resource specified in 
the Request-URI along with all its internal members, all the way down 
the hierarchy, are to be locked. A successful result MUST return a 
single lock token which represents all the resources that have been 
locked. If an UNLOCK is successfully executed on this token, all 
associated resources are unlocked. If the lock cannot be granted to all 
resources, a 409 (Conflict) status code MUST be returned with a response 
entity body containing a multistatus XML element describing which 
resource(s) prevented the lock from being granted. Hence, partial 
success is not an option. Either the entire hierarchy is locked or no 
resources are locked."


By that definition, it looks entirely reasonable that the presence of a 
a redirect shouldn't affect the result of a deep lock request at all (if 
there's a redirect in scope, the redirect itself should be locked as well).

My proposal is that we go through the list of methods that use the Depth 
header, and define the expected outcome separately (rewriting the whole 
section of 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-12.html#rfc.section.8>). 
   That may take some time, but will surely be worth the effort if more 
servers will actually be able to implement the spec.


Feedback appreciated,

Julian
Received on Sunday, 3 July 2005 18:09:04 GMT

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