- From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
- Date: Fri, 22 Jun 2001 10:02:01 +0100
- To: "'Alan Kent'" <ajk@mds.rmit.edu.au>
- Cc: w3c-dist-auth@w3.org
Bits snipped, all IMHO. As usual, corrections please. > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 21 June 2001 06:43 > To: w3c-dist-auth@w3.org > Subject: Is this LOCK model correct? > > WebDAV talks about moving a resource under one locked > collection to under > another locked collection, and the old lock being lost and > the new lock > being gained. I am trying to get the semantic model in my head right. > Comments on my model below would be appreciated. > > I am trying to work out if you do a LOCK with depth infinity, what is > actually locked. Are the resources locked, or the URI's to > the resources? I think the lock applies to the URIs and any descendant of it. Imperfect example is a file system implementation. Infinite depth lock is applied to a directory and all its descendants (sub directories and files). Oh and of course, as HTTP/WebDAV are "root directory" based, a request with infinite depth lock on root (if permitted) would lock the entire server. Yes this does have uses, e.g. an administrator wants to perform a backup but nobody can make changes in the meantime. RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs" and "LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable." If you think about it, the first statement makes sense when you consider the second statement. However, I think the server applies locks to resources, but our visualisation is that locks apply to URIs. > Since some of the lock description is URI based, and other > says resources > are locked, I have come to the following model of locking. > Please correct > me if its wrong: > > - Locks are based on URIs. See above. > > - A depth 0 lock puts a lock on that URI only. Depends on what you mean. A resource can have one or more URIs mapped to it (RFC 2518 sec 5.1). The resource would be locked and thus all the URIs that map to it. So no matter what URI (that was mapped to the resource) that was used by the client, the resource would appear to be locked as far as the client is concerned. However, none of the descendants would be locked. > > - A depth infinity lock identifies the leading path of a URI > - any URI with > additional path components is covered by the lock as well. Correct, although you might want to word it a little different - "descendants" is probably better. > > - To check if a resource is locked, *all* of the URIs to the resource > (if multiple bindings exist) must be checked against the locks that > currently exist. As stated above, a resource MUST NOT be locked if the lock cannot be honored by all the URIs which address it. You shouldn't have an occurrence where a resource is locked, but using a URI that maps to it indicates the resource isn't lock. So in *theory*, you shouldn't have to check all the URIs because any of the URIs (that map to the locked resource) can be used to discover that the resource is indeed locked. > > In my understanding, locks are not really associated directly with > resources because moving things to different URIs does not keep the > lock. So the lock is not independent of the URI - hence locks are > really best thought of as attached to URIs. Resources are locked > if any of the URIs to the resource is locked. > > Alan > Of course, its all a lot simpler if your server only supports one URI per resource. It makes the understanding of locking a lot easier :-) Regards Shaun Hall Xerox Europe
Received on Friday, 22 June 2001 05:04:03 UTC