Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: "Hall, Shaun" <[email-masked]>
Date: Tue, 31 Jul 2001 13:44:18 +0100

Not criticising/bashing the vendors/implementors...

> -----Original Message-----
> From: Alan Kent [mailto:[email-masked]]
> Sent: 31 July 2001 10:21
> To: [email-masked]
> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> 
> 
> On Tue, Jul 31, 2001 at 09:59:59AM +0100, Hall, Shaun wrote:
> > I don't think LNRs should be changed at all.
> > 
> > You could use a file to track the lock if you wish and you won't be
> > deviating from the RFC.
> > 
> > The RFC doesn't place restrictions on implementation (in 
> this case LNRs) -
> > you can basically use whatever you want, so why are you 
> suggesting that the
> > semantics should be changed ?
> > 
> > Its an implementation problem, not a protocol problem.
> 
> My understanding of the current state of play is that the RFC allows
> a LNR to be created which may be either a placeholder for a collection
> or a non-collection resource.

Agreed.

> 
> Some implementations want to create a temporary file for a 
> lock to store
> properties or stop other systems behind the scenes creating the
> same reseource - which wont work because MKCOL will then fail because
> a file exists.

Implementation problem. The server should delete the file before it creates
the collection (assuming all tests have passed). Yes it takes system
resources (CPU time etc).

Lets remember folks that in one sense, WebDAV turns the web into a writable
medium, and writing is slower than reading.

> 
> Some existing implementations (I think it was IIS and/or Apache) if
> you unlock without doing a PUT or MKCOL leave a dead file behind.
> I think this not conformant to the the RFC.

Agreed. In the current spec, the server should delete the file. Again
implementation problem.

> 
> My general feeling was enough people said "LNR should stay", so it had
> been recommended to change the RFC so that
> 
> (1) existing implementations could be considered conformant and
> 
> (2) new implementations could use a file simplifying compatibility
>     with other systems.
> 
> This is why I thought it had been proposed that the RFC be changed so
> LNR's are only for PUT and not MKCOL, and so that servers were not
> *required* to clean up if a LOCK was followed by an UNLOCK without
> a PUT.

Some people have suggested to do away with LNRs completely, not just for
MKCOL.

The purpose of LNRs are to "lock the name" (RFC 2518 sec 7.4), which is in
line for PUTs and MKCOLs. If you drop support for MKCOLs, then you might
confuse readers as you've diluted this statement.

What happens if you don't support LNRs for MKCOL? As an example, two
requests are submitted by two different users to a server, one to perform a
MKCOL (without LNR support) and one to create an LNR (LOCK), both with the
same URL.

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 could cause problems for the user who created
the collection because they are not the owner of the lock.

The above wouldn't happen if you used LNRs for MKCOL as well, because the
2nd LOCK request would fail.

> 
> The above may be wrong - I don't have the RFC handy. The above is
> simply what I understood of the current state of play.
> 
> Alan
> 

Corrections, comments etc welcome.

Regards

Shaun Hall
Xerox Europe

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 31 Jul 2001 06:59:19 -0700

> 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

Assuming the user could tell if they created a new collection or not --
what's the problem?

> 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

---

From: Alan Kent <[email-masked]>
Date: Wed, 1 Aug 2001 12:19:17 +1000

On Tue, Jul 31, 2001 at 01:44:18PM +0100, Hall, Shaun wrote:
> confuse readers as you've diluted this statement....

Personally, I am not too stressed whichever way things go - I have not
implemented locking yet! :-)

Regarding LNR's being dropped - yes, it was suggested, but I think
enough people said "it should stay" so that it will not be removed.

There was another problem area brought up, which I can appreciate.
Its that LOCK for some implementations cannot be guaranteed to be
implemented fully and correctly. For example, consider WebDAV being
an interface onto a UNIX file system. (In my own case, its on to
a database containing web resource objects such as collections
and files. Sticking with a UNIX file system is easier to explain.)

So there is a WebDAV library sitting above the file system API.
Users of WebDAV always come in via the WebDAV library. Other
applications however can go directly to the file system.

  +----------------+ +----------------+ 
  |                | |                |
  | Application 1  | | Application 2  |
  |                | |                |
  +----------------+ +----------------+ 
           |               |
  +----------------+       |
  |                |       |
  |  WebDAV Layer  |       |
  |                |       /
  +----------------+      /
             \           /
           +----------------+
           |                |
           |   File System  |
           |                |
           +----------------+

If the WebDAV layer implements LOCK itself, then it can protect a
web resource against other WebDAV clients, but it cannot protect
itself against other applications going in via a different API.

The solution is for the WebDAV layer to translate the LOCK request
into a file sytem lock request. Then the lock will be honoured by
all applications (not just WebDAV clients).

Lock null resources however have unusual semantics in terms of what
most other systems implement. I don't think the UNIX file system,
for example, has the concept of locking a file name so other applications
cannot use it without a file being created.

There are possible solutions. For example, create a file, lock it,
then if the WebDAV client issues a MKCOL, delete the file and create
a directory instead and hope another application does not sneak in
with a race condition and create the directory first. (Deleting the
file I believe will delete the lock.) But this defeats the purpose of
a lock, doesn't it? It does reduce the chance of a race condition, but
it is not a guarantee.

To summarise: I can implement LNR in the WebDAV layer easily. But as
soon as the underlying data store is accessible by an means other
than WebDAV, the locking model (for a 100% correct implementation of
locks) must be pushed down into a common layer. I believe the problem
with the WebDAV LNR is that it is not a commonly implemented scheme for
locking by other systems, so it will be hard for implementors to
implement correctly according to the spec.

The choices (in my opinion) then are

(1) Its ok for implementors to not implement locking safely - its just
    an aid for applications, not something they should rely on.

(2) Locking is only to protect against other WebDAV clients and not
    against anything else

(3) WebDAV is only for use when the underlying storage model supports
    the LNR concept

(4) The locking model needs to change

I think (3) is not an appropriate choice for WebDAV as it restricts its
scope too much (I don't know of any other system that supports LNR).
I think (2) is silly - what is the purpose of locking if they don't work?
I think the real choices are (1) or (4). With the current WebDAV spec,
(1) is the only choice to me.

Alan