- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 08 Jun 2004 11:31:10 +0200
- To: w3c-dist-auth@w3.org
- Cc: Lisa Dusseault <lisa@osafoundation.org>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Jason Crawford <ccjason@us.ibm.com>
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) OK, I just tested Adobe Golive (the client besides our own I'm aware of using shared locks) with Apache/moddav, trying to get an exclusive lock on a resource that already has a shared lock. The response from Apache/moddav is a 423 Locked, so no Multistatus. Unless I'm missing something this means that the marshalling shown in section 8.10.10 of RFC2518 (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) indeed won't help any clients at all; and as it is underspecified we should just get rid of it. Proposed changes: 1) Change section 8.10.2 (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>) to say: "The response for a successful LOCK creation request MUST contain the value of the lockdiscovery property in a prop XML element." 2) When we define named preconditions, define a content model for the precondition that will reveal the lockdiscovery property. Jason, could you please add this to the issues list? (I'm adding this to my list as <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.8.10.1_lockdiscovery_on_failure>, please let me know if should rephrase it). Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 8 June 2004 05:31:48 UTC