Re: LOCK error marshalling (lockdiscovery property included?)

Julian Reschke <julian.reschke@gmx.de> wrote on 06/05/2004 06:36:11 AM:

> Geoffrey M Clemm wrote:
> 
> > I don't think anything needs to be changed here.
> > I'm not sure what you had in mind by saying
> > "it MUST be returned on successful execution",
> > since the whole point is to indicate what existing
> > lock caused the LOCK request to fail, i.e. this
> > property is returned only for the failure case.
> 
> In RFC2518, the requirement is independant from the success of the LOCK 
> request: "The response MUST contain the value of the lockdiscovery 
> property in a prop XML element." 

By "this property", I meant the property on the nested resource that
returned 424 because that nested resource was already locked.
I agree that a lockdiscovery property for the resource identified
by the request-URL must always be returned, whether or not the request
succeeded.

> 1) For a successful LOCK creation, returning the element makes a lot of 
> sense, because the client can check the actual state of the lock (did 
> the server accept my Timeout header? what did it persist in the 
> DAV:owner property?). I think that part is widely implemented and if 
> fact used by popular clients such as MS Office (it checks the response 
> body to decide whether the created lock is really what it wanted). 
> Therefore we should keep that part, and this is why I was saying "MUST 
> be returned on success".

Yes, I agree.

> 2) For a failed LOCK request, there are (at least) two scenarios:
> 
> 2a) The resource at the request URI can not be locked, for instance 
> because it already has a conflicting lock. In that case, I'd expect a 
> 4xx status code, and RFC2518 does not define a way to send back 
> DAV:lockdiscovery. If we require the server to send back a 207 with 
> response body in this case, this really needs to be stated explicitly 
> because it's far from obvious.

Well, it is stated in section 8.10.4, but I agree that it is not clearly
stated, since the only way to guess how to marshall it is by extrapolation
from example 8.10.10.

> 2b) The client tries a deep lock, and some of the descendants of the 
> resource identified by the request URI can not be locked. In that case 
> 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>), 
> the text requires a 409 and a multistatus body (this is a bug in both 
> RFC2518 and RFC2518bis, it should be 207, 
> 
see...:<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3
> >). 

Yes, that inconsistency in the spec doesn't contribute much in the way
of clarity (:-).

> In that case, the DAV:lockdiscovery property for the resource at the 
> request URI will usually be empty, and it escapes me why anybody would 
> want to send that back to the client.

It might not be empty because there might already be a shallow
lock on that collection.  So returning the lockdiscovery property
tells the client definitively whether or not there already is a
lock on the request URL resource, which is useful information when
dealing with the failure.

> > WRT the marshalling, I agree that this is not a
> > consistent way of using the propstat syntax
> > (i.e. the status is not about the property,
> > but that was just a convenient place to put it).
> > So if nobody implements this,
> > we certainly could define a cleaner marshalling,
> > but if any client/server does implement it, then we
> > should leave it alone.
> 
> Let's find out.

Yup.

Cheers,
Geoff