W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: LOCK error marshalling (lockdiscovery property included?)

From: Jim Luther <luther.j@apple.com>
Date: Mon, 7 Jun 2004 15:17:32 -0700
Message-Id: <78857BAE-B8D0-11D8-AECF-000A95DC65E0@apple.com>
To: w3c-dist-auth@w3.org

The Mac OS X WebDAV file system client uses exclusive locks. The 
lockdiscovery property is only used if LOCK is successful.

- Jim

On Jun 7, 2004, at 2:37 PM, Lisa Dusseault wrote:

>
>
> 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 18:18:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT