Re: Should REBIND preserve locks, other live properties

I agree with Julian's responses.

In addition, a client-side motivation for the "delete on MOVE" behavior of
locks is that it simplifies client-side lock management.  When the
client locks a resource, it just adds the request-URL of the lock
and the returned lock token to its list of URL/lock-token pairs.
It knows that that lock-token will be at that URL for the lifetime of
that lock-token.  If locks were not deleted when the protected URL
was unmapped, it is harder for a client to keep track of its locks.

Cheers,
Geoff 


Julian wrote on 03/19/2004 04:48:07 AM:

> Lisa Dusseault wrote:
> 
> > In RFC2518, a MOVE operation is supposed to destroy all locks on the 
> > moved resource and any descendants.  This behavior is unlike most 
> > filesystems.  Yaron laid out the reasons but they weren't too strong. 
> > Basically the reasons why not amounted to the fact that some systems 
> > that didn't support bindings couldn't do this easily.
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html
> > I'd assumed that a REBIND was different than MOVE, and couldn't be 
used 
> > in as many cases.  If a REBIND is really the same as a MOVE then why 
are 
> > we defining it?  If it's different -- e.g. if , as I had assumed, 
REBIND 
> 
> Because RFC2518 allows servers to implement MOVE as COPY/DELETE, and 
> BIND can't override that (when it tried, we got complaints from people 
> who rely on MOVE working as it does).
> 
> > is "safer" and more high-fidelity than MOVE (but can be used in fewer 
> > cases) then we need to understand how it's different.
> >
> > If REBIND can be different than MOVE, then we can make a number of 
> > things work better (more predictable) from a client point of view:
> >  - locks aren't destroyed, lock token doesn't change, the lock state 
> > appearing on other bindings doesn't change
> 
> However, the locking model we all agreed on (remember? -> 
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>) 
> explicitly says...:
> 
> - If a request causes a directly locked resource to no longer be
>    mapped to the lock-root of that lock, then the request MUST
>    fail unless the lock-token for that lock is submitted in the
>    request.  If the request succeeds, then that lock MUST have been
>    deleted by that request.
> 
> So REBIND behaves exactly as the locking model is predicting it: a 
> namespace operation causes the locked resource not being mapped anymore 
> to the lock root, and thus the lock is removed.
> 
> Changing this would mean that the locking model needs to made more 
> complicated (again). In this case, we couldn't talk about namespace 
> operations in general, but would need to go back to special cases.
> 
> Unless there's a clear benefit from that complication, I vote with "no".
> 
> >  - getlastmodified date doesn't change unless another resource is 
> > overwritten (for that matter, we could specify that REBIND can't 
> > overwrite another binding which would make it even simpler), so the 
> > getlastmodified date on other bindings doesn't change
> 
> Again, this is incompatible with HTTP semantics for the Last-Modified 
> header, please see my other mail 
> 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0108.html>).
> 
> >  - etag doesn't change...
> 
> Same.
> 
> >  - live properties have more guarantees in how they are preserved
> 
> Live properties aren't affected except for the unfortunate cases where 
> they are. Same behaviour as in RFC2518.
> 
> >  - ACLs aren't re-inherited?
> 
> If you're talking about 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.
> html#PROPERTY_inherited-acl-set>: 
> no, they aren't.
> 
> >  - this makes a "rename" operation work exactly as the client expects 
it 
> > would (not the case today with MOVE)
> > 
> > If a server can't implement REBIND -- well, there's still MOVE.
> 
> Lisa, the issue is that namespace operations in HTTP *can* *not* behave 
> as in filesystems as far as HTTP headers such as "Last-Modified" or 
> "ETag" are concerned -- this is just incompatible with HTTP, so there's 
> no way to require it.
> 
> We *can* encourage servers to use "robust" ETags (Etags that are unique 
> across all resources in the namespace) and thus don't have conflicts 
> with ETags that may have been previously used for the same URL. But 
> that's a general rule, not particular to BIND whatsoever, so if you 
> think it's worth the effort, add it to RFC2518bis.
> 
> Regards, Julian
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Friday, 19 March 2004 08:34:35 UTC