RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Not criticising/bashing the vendors/implementors...

> -----Original Message-----
> From: Alan Kent [mailto:ajk@mds.rmit.edu.au]
> Sent: 31 July 2001 10:21
> To: w3c-dist-auth@w3.org
> 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

Received on Tuesday, 31 July 2001 08:44:31 UTC