- From: Jim Luther <luther.j@apple.com>
- Date: Mon, 7 Jun 2004 15:17:32 -0700
- 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 UTC