- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 31 Jul 2001 06:59:19 -0700
- To: "Hall, Shaun" <Shaun.Hall@GBR.XEROX.COM>, "'Alan Kent'" <ajk@mds.rmit.edu.au>, <w3c-dist-auth@w3.org>
> Say the MKCOL is executed first, then the LOCK (LNR) second. The MKCOL > succeeds and creates a collection that isn't locked. The LOCK request > (attempting to create an LNR) is then performed on this newly created > collection. What will happen? Since LOCK requests do not > distinguish locking > null resources from existing resources, the server will most > likely lock the > newly created collection. THIS is, I believe, an actual problem. Even with lock-null resources the way they are, clients MUST be able to tell the difference between a LOCK that created a new thing, and a LOCK that locked an existing thing. There's a simple way to do this: 201 vs. 200. I believe it was only an oversight that the list of error codes for lock does not include 201, and I consider it an errata for 2518. > This could cause problems for the user > who created > the collection because they are not the owner of the lock. Assuming the user could tell if they created a new collection or not -- what's the problem? > The above wouldn't happen if you used LNRs for MKCOL as well, because the > 2nd LOCK request would fail. I do not think that is correct. The second lock request would lock the existing collection -- as you said two paragraphs up. Lisa
Received on Tuesday, 31 July 2001 10:15:06 UTC