Re: LOCK error marshalling (lockdiscovery property included?)

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." 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>).

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".

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.

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>). 
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.

> 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.

Best regards, Julian

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

Received on Saturday, 5 June 2004 06:36:47 UTC