- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 23 Jun 2001 23:24:34 -0400
- To: w3c-dist-auth@w3.org
From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] 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. Note: I will be arguing vigourously that we delete the "locks apply to resource, not URIs" phrase from the next draft of 2518. I believe this statement has proven to be very confusing and misleading. We should replace this with "a lock is on a URI, and a resource is locked if it is mapped to a locked URI". > - 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. Yes, you'd probably want to supplement this statement to make sure it is not misunderstood. Something like: "but the lock controls access to that resource, even when that resource is accessed through another URI". > - 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. Yes, the protocol does require that all the locks that affect a resource (from any URI) appear in the DAV:lockdiscovery property of that resource, so you just need to look at that property. Now an implementation may implement that property by a scan against all locks that exist on a URL that is mapped to that resource, but that's an implementation choice. > 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. 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 :-) Yes, 2518 largely ignores the use case where one resource is mapped to multiple URI's (thus there was no BIND method, and DAV:lockdiscovery did not expose the URI that was locked). But we'll fix all that in the upcoming new draft of 2518 (:-). Cheers, Geoff
Received on Saturday, 23 June 2001 23:18:55 UTC