RE: Interop issue: Proposal for fixing lock token provision

On Friday, 09/27/2002 at 09:42 AST, "Clemm, Geoff"
<nngclemm___at___Rational.Com@smallcue.com> wrote:
> In particular, I do not find the "separation of concerns" argument
> convincing, since issue #3 (detecting when you have an
> invalid lock token) is exactly the reason why a single header
> is used both to check state and demonstrate possession of the
> required token (i.e. I believe the concerns are inherently linked).

I actually just figured out what that case is, but I don't want to
focus on that in this note.   I'd first like to discuss moving
 the token submission functionality to a different header.


> In particular, I do not support #2, because it leads a client to
> perform updates against resources that it has lost its lock on.
They probably should be checking for an etag rather than a
lock anyway.  If the client is only doing content editing, the lock
check is just something that can be done if you don't have etag
support.  If the etag hasn't changed, you are probably fine doing
the PUT operation just checking the etag.    And in fact doing
the etag checking will allow the client to check for content
changes that occured despite the fact that he locked locked the
resource.

You could check both the etag and the lock.  But if it's the last
PUT operation you plan to do before unlocking, checking the lock
is just going to make things chatty and delay the PUT that you'll want =
to
do anyway.  Why?  Because if someone as aquired a new
lock, you'll be told anyway.   And if someone modified the
resource, the etag check will already catch this.   Finding out there
is no lock there if you' just going to unlock anyway doesn't do
any good.

Better servers support etags, but some won't or won't be able
to.  In this case, the best the client can do is check for lock
still being there.  The client should do that.  And in the case of
property modifications (which don't change etags), they'll want
to check for locks rather than etags anyway.   This will let them
know if another client has had a chance to modify the resource.

But I think this is a client responsibility.  The server should
not force the client to do this.  It's up to the server to offer lock
support and to correctly implement it.  And it's up to the client
to use them as it needs to.  We already allow a client to decide
if it uses locks.  Let it also be the case with this.   I've already
indicated a case above where it wasn't appropriate to
check for a lock.   Let the client decide.


> Why would a client ever want to do that, instead of reacquiring
> a lock?
If they successfuly check the etag, it doesn't matter if they still
have the lock.

> A key benefit of locks as currently defined is that they
> solve the lost update problem for servers that cannot provide etags,
Yup.  So if a server supports etags, the client often doesn't need to
check for the lock.

> but updating a resource for which you have lost your lock
> opens you up to the lost update problem.

...in the absense of etags.

> Note: If lengthy If headers has proven to be a problem, I am
> happy to allow a "," to separate If clauses, so that
> you can submit multiple If headers in one request.

It's not really the length that's the problem in my mind.  It's
the fact that we have to define what it means for the If:
header to have *submitted* the token.  The If: header
can be quite sophisticated and we might choose to make
it even more sophisticated as we discover more requirements.
If we combine the functionality, then it constrains how much
we can extend the If: header.

Yes, we could say that clients can support multiple If:
headers.  (I forget if we already do.)  But we'd end up
defining two types of If: headers for the two purposes.

I'd prefer to seperate those explicitly.  WebDAV is only
in version 1 now and hopefully a design decision like
this will clarify the protocol now and avoid specification
headaches down the road.

J.=

Received on Monday, 30 September 2002 10:42:39 UTC