Re: Interop issue: Proposal for fixing lock token provision

Am Montag, 30.09.02, um 16:33 Uhr (Europe/Berlin) schrieb Jason 
Crawford:

I agree with Jasons arguments concerning the update of resources
with PUT and using ETags in order to detect unexpected changes.

However, when the client wants to change properties, access rights
or version information (e.g. checkin), then the ETag will not tell
anything useful about the status of the resource.

For these use cases clients will continue to need the lock-token(s)
in the If: header.

In the light of this, is it useful to add another header where lock
token can also be supplied? What do client implementors say?

//Stefan

> [...]
>
>> 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 11:02:58 UTC