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

Well, the 424 is returned for the request resource (because it has a 
failed dependancy). The non-424 status (in the RFC2518 example 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> it's 
a 403) comes without the DAV:lockdiscovery property (and I do agree that 
it may be useful here, but that's not what the spec says).

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

...but the multistatus response body is only mentioned for marshalling 
failures due to depth:infinity...

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

In the meantime I found out that at least Apache/moddav and Sharemation 
indeed use this format. What we should do...:

1) Find out whether there are clients that actually process this 
information. As far as I can tell, it will only be useful if and only if 
you're trying to get an deep, exclusive lock on a resource that already 
has a shared lock. I'm only aware of two clients using shared locks. The 
first one being our own (and I know it doesn't use that information), 
the other being Adobe GoLive (for which I'll check).

2) If the answer is "yes" *and* we agree not to break them, we'll need 
to figure out how to precisely define that response format (a single 
example is not good enough).

3) On the other hand, if the answer is "no" let's define what we *like* 
the protocol to do and come up with a cleaner design (precondition code 
with nested content as in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?


Best regards,

Julian


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

Received on Sunday, 6 June 2004 05:55:52 UTC