- From: Greg Stein <gstein@lyra.org>
- Date: Sat, 11 Mar 2000 01:46:30 -0800 (PST)
- To: "Slein, Judith A" <JSlein@crt.xerox.com>
- cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, "Hall, Shaun" <Shaun.Hall@GBR.XEROX.COM>
FYI, mod_dav removes all the locks. e.g option (a) was our interpretation Cheers, -g On Fri, 10 Mar 2000, Slein, Judith A wrote: > I have this question from a product team in my company. Any opinions? I > would say that (b) is not an option, but failing the unlock request might > be. > > --Judy > > Section 8.11 UNLOCK Method. The first sentence states "...and all other > resources included in the lock". Does this mean that a client should only > Unlock from the point where the lock starts? For example, in a hierarchy: > > Collection 1 > | | > Collection 2 Collection 3 > | | > Resource 4 Resource 5 > > If the lock was created with a Depth of infinity on "Collection 1", should > the user only perform the UNLOCK on "Collection 1"? > > We're concerned that a client may try and unlock from a sub-point within the > hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence > in the RFC, we either: > > a) Have to traverse the entire hierarchy (parents and all) removing the lock > from all resources (in the above example, "Collection 1", "Collection 3" and > "File 5"). > > b) Only remove the lock from "Collection 2" and "File 4". > -- Greg Stein, http://www.lyra.org/
Received on Saturday, 11 March 2000 04:43:16 UTC