Re: LOCK error marshalling (lockdiscovery property included?)

Hello client implementors! -- please respond on this thread and let us 
know if you use the 'lockdiscovery' property value, which is returned 
in failed LOCK requests.

(If no clients use the property value as returned in failed LOCK 
requests -- maybe they all do another round-trip to get the value -- 
then we might as well simplify, rather than optimize for this failure 
case)

Lisa


On Jun 6, 2004, at 2:55 AM, Julian Reschke wrote:

>
> 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 Monday, 7 June 2004 17:38:25 UTC