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

I agree with Julian that the Depth infinity section of redirectref should
be redefined based on this implementation experience.

Cheers,
Geoff

Julian wrote on 07/03/2005 02:08:31 PM:
> 
> 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
>