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

Re: LOCK error marshalling (lockdiscovery property included?)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 08 Jun 2004 11:31:10 +0200
Message-ID: <40C5875E.2060600@gmx.de>
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)


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:29 UTC