RE: Locking a Resource or Locking a URL?

RFC 2518 requires that a LOCK lock a resource. A reference is a resource. A
LOCK against a reference MUST lock the reference. The current spec states
that the default behavior for locks against direct references is to lock the
target and not the reference. This is a violation of RFC 2518.

Let us say, for the sake of argument, that the advanced collection spec was
changed such that the default behavior was to lock the reference and not the
target. This would seem to satisfy my previous point. However, I would still
argue that the advanced collection spec is non-compliant with RFC 2518. My
reasoning is as follows:

Meet my RFC 2518 compliant word processor. The user goes to the file open
dialog and types in the URL of a reference. The word processor proceeds to
take out a write LOCK on the reference and to GET its contents. The word
processor now assumes that the contents of the resource will not change as
long as the write LOCK is outstanding, RFC 2518 makes this assumption
completely legal. In reality, however, the word processor has only locked
the reference, not the target. Thus it is possible for two GET requests on
the resource to return different results even though a write LOCK is
outstanding. Thus the word processor's legal assumption that as long as the
write LOCK is outstanding the GET response won't change has been violated.

Thus it is a violation of RFC 2518 to have the default behavior of LOCKs on
references be to only lock the reference. The default behavior must be to
lock both the reference and the target.

Which brings us to redirect references. I suspect the only thing we can do
there is to have the default behavior be that the LOCK fails with a 302.
This is reasonable, especially in the case of collections, because RFC 2518
is crystal clear that a depth LOCK on a collection ATOMICALLY locks all its
contents. Clearly a redirect reference can not enforce the atomic
requirement so failure is the only option. However, once you send in a
no-passthrough header, all bets are off and you are free to just lock the
redirect reference.

				Yaron Y. Goland
				Commissioner
				WebDAV Police Department (WPD)

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, February 26, 1999 9:31 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Locking a Resource or Locking a URL?
> 
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    O.k. I'm completely lost. Let's try this again.
> 
>    I have a resource which is available through two names, 
> http://foo/bar and
>    http://iggy/pop. Someone requests and receives an 
> exclusive write lock
>    against http://foo/bar. I assert that the immediate 
> consequence is that
>    http://iggy/pop is ALSO write locked by the same principal.
> 
> Good, this means we can rule out #2 as being clearly wrong.
> I believe we also agree that #1 is true (after all, that's what
> the spec says).
> 
> So all that's left (and that was the actual intent of this thread),
> is to determine if it is legal for an RFC-2518 compliant 
> server to allow
> a *different* resource to appear at http://foo/bar after a
> "LOCK http://foo/bar" request has been issued.
> 
> I believe the answer is "yes", since RFC-2518 only talks about
> what it means when a resource is locked, so if a server associates
> a different (unlocked) resource with a URL (or if some 
> extended protocol
> allows a client to associate a different resource with a URL),
> then this does not violate locking behavior as defined in
> RFC-2518.
> 
> Another way of phrasing this is that the URL(s) currently used
> to reference a resource are *not* a property or attribute of the
> resource, so changing the URL that is used to reference a resource
> does *not* violate any locks that might be on that resource.
> 
> Both references and versioning introduce mechanisms for the client
> to explicitly modify the association of a specific resource with
> a specific URL, and I believe this subtlety is at the heart of
> our disconnect on advanced collection locking.
> 
> Yaron: We may need to add this to our "Minneapolis Poolside Agenda"
> if email isn't cutting it (and yes, I *always* bring my cool markers
> to IETF conferences :-).
> 
> Cheers,
> Geoff
> 
>    > -----Original Message-----
>    > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>    > 
>    > ...  the question of what gets locked when you lock a resource.
>    > 
>    > There are (at least :-) three interpretations:
>    > 
>    > (1) You are locking only the resource.
>    > 
>    > (2) You are locking what appears at a given URL (i.e. if 
>    > the resource
>    > currently selected at that URL also appears at another 
>    > URL, then the
>    > lock does not apply to accesses through that other URL).
>    >
>    > (3) You are locking both the resource and the fact that 
>    > the resource appears at the given URL.
>    > 
>    > ...
>    > In this message, I would like to confirm that nobody 
>    > believes that
>    > (2) is the correct interpretation.  In particular, I 
>    > would like to
>    > confirm that if /a/x.html and /b/y.html happen to be the 
>    > same resource
>    > (by some quirk of the server, say), and /a/x.html is locked, then
>    > a PUT to /b/y.html would fail without the appropriate lock token.
> 
>

Received on Friday, 26 February 1999 15:22:44 UTC