W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

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>
Message-ID: <HPELJFCBPHIPBEJDHKGKGEJBCKAA.lisa@xythos.com>

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT