RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Bits snipped. All IMHO.

> -----Original Message-----
> From: Alan Kent [mailto:ajk@mds.rmit.edu.au]
> Sent: 01 August 2001 03:19
> To: w3c-dist-auth@w3.org
> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> 
> Sticking with a UNIX file system is easier to explain.
> 
> 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.

I think you are taking WebDAV out of its intended context (see below).

You don't need race conditions because your WebDAV layer in the above
example can be circumvented full stop. For example, there's nothing to stop
another non-WebDAV application creating a directory with the same name as
the LNR even though your WebDAV server has created a LNR. As far as the
WebDAV client is concerned, they have reserved the name. When your server
tries to create the directory (after a MKCOL), it will fail unless you
delete the existing directory first which probably wouldn't be very popular
(and the failure may confuse the client).

Unless the heart of your "back end" (in this case a OS's file system)
supports WebDAV, its going to be a "best effort" approach.

Everything is difficult (not just the LOCKing mechanism) when you have
multiple protocols into the same shared data area. Unless there is some
common base "controller", you will always run into these sort of problems.

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

Actually 2) is correct as well:

Remember that WebDAV is a set of extensions to HTTP, which suffers similar
problems. WebDAV is about WWW functionality, not a "be all and end all"
access mechanism for everything - see section 1 of RFC 2518, read RFC 2291.
This is what I mean when I say you've taken WebDAV out of intended context.
Your example of other applications accessing your Web/WebDAV Server's data
area is not WWW functionality and therefore WebDAV does not apply IMHO.
People have to live with it. Is WebDAV going to stop admins/root formatting
the hard disk which contains the data ?

In your file system example, there is nothing to stop another application
deleting a file (that is not a LNR) that your WebDAV Server has locked.
Therefore the locking mechanism has failed. What mechanism can you invent
that would solve all these multiple protocol problems? This is NOT a WebDAV
problem, but occurs whenever you have multiple paths/protocols/etc into a
shared data area.

In the real world, the end users system in question should be configured so
only HTTP/WebDAV clients can access the data area that the WebDAV Server
interacts with. If this cannot be done, there is not a lot you can do about
the WebDAV protocol being circumvented. Simply because you as a WebDAV
implementor do not have full control (unless you start writing OS file
system drivers :-).

> 
> Alan
> 

Regards

Shaun Hall
Xerox Europe

Received on Wednesday, 1 August 2001 05:30:31 UTC