RE: 423 Locked

When someone does a MOVE or a COPY or a PROPPATCH etc.  We have the ability
to tell them why the operation failed (in XML in the body).  With 423 we do
not.  I don't think that sending the extra information (based on security
considerations) is wrong.

If I do a MOVE on a resource to a destination which already exists, I think
it would be useful information to say that the source was locked vrs. the
destination was locked.  Since this information would be useful, why not
also send the info Rickard is looking for?

I don't think that we should simply return the lockdiscovery...  In the
future we are going to need to provide some better syntax for reporting
errors.  My suggestion is that we return the lockdiscovery stuff, but wrap
it in some new set of tags which can also give the href and will be used in
other places.

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of jamsden@us.ibm.com
Sent: Thursday, February 03, 2000 9:28 AM
To: w3c-dist-auth@w3.org
Subject: Re: 423 Locked




Like Geoff, I don't think there should be too much problem doing the
PROPFIND after the failed lock. The only thing that can happen between the
LOCK and the PROPFIND that would be of interest is UNLOCK, and then the
client would see the lock was gone and there is nothing to do (always a
possibility in a distributed, concurrent environment). We have to be
careful about overloading methods to support client use cases. This will
cause the protocol to bloat and become complex. It will also reduce
interoperability and create situations where one client's use cases
conflict with another. Some methods do return failure information that your
client can use.




falk@excosoft.se on 02/03/2000 11:29:48 AM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:

Subject:  Re: 423 Locked


Hi!

If you follow the 423 Locked thread, you see that I suggested that the
lockdiscovery should be sent in the 423 response. I would like the 423
response
to contain the locked by info, so that I don't have to do a new request to
the
server ( performance ), and not have a time gap.
Do you have any comments about sending the lockdiscovery in the 423
response, I
would appriciate getting them... ( or if you can post them on the webdav
work
group...)

/Rickard

>
>
> There is a DAV property called DAV:lockdiscovery which contains a
> DAV:activelock element which contains, among other things, a DAV:owner
> field describing the owner of the lock. The WebDAV spec does not define
the
> content of the DAV:owner element, it only suggests that it should
describe
> the owner of the lock in some way that another user could contact the
> owner. Unfortunately, there is no element in DAV:activelock that
specifies
> the actual princapal that took out the lock. I believe this is a bug that
> requires all clients to maintain their lock tokens in some other
redundant
> repository. This issue has been open for over a year. I hope it gets
> addressed and resolved as part of the ongoing effort to clarify WebDAV
> locking semantics and protocol.
>
>
>
>
>
> "Rickard Falk" <rickard.falk@excosoft.se>@w3.org on 02/03/2000 03:46:52
AM
>
> Sent by:  w3c-dist-auth-request@w3.org
>
>
> To:   <w3c-dist-auth@w3.org>
> cc:
>
> Subject:  423 Locked
>
>
> If a resource is locked with a exclusive lock, and another user tries to
> lock if. The response then is 423 Locked. But, is there any way for the
> client to know who owns the lock?
> I would like the response to look something like this :
> 421 Locked
> Date: ...
> Server: ...
> Connection: ...
> LockOwner : user
> LockDate  : date
> LockType  : exclusive
> LockedUntil : date         // if specified when locked
>
> Comments?
>
> /Rickard
>
>
>
>

Received on Thursday, 3 February 2000 14:15:22 UTC