Subject: Re: 423 Locked

From: [email-masked]
Date: Thu, 3 Feb 2000 12:28:23 -0500

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.

[email-masked] 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" <[email-masked]>@w3.org on 02/03/2000 03:46:52
AM
>
> Sent by:  [email-masked]
>
>
> To:   <[email-masked]>
> 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
>
>
>
>

---

From: [email-masked] (WJCarpenter)
Date: Thu, 3 Feb 2000 10:21:04 -0800

jamsden> We have to be careful about overloading methods to support
jamsden> client use cases. This will cause the protocol to bloat and
jamsden> become complex. It will also reduce interoperability and
jamsden> create situations where one client's use cases conflict with
jamsden> another. Some methods do return failure information that your
jamsden> client can use.

You also have to allow for the possibility that it's more expensive
for a server to answer questions about the details of a LOCK than it
is to merely answer yes-or-no about a resource being LOCKed.  (E.g., a 
fixed field in some property table points to a LOCK record stored
elsewhere.)
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Greg Stein <[email-masked]>
Date: Thu, 3 Feb 2000 10:43:39 -0800 (PST)

> jamsden> client use cases. This will cause the protocol to bloat and

I thought we were designing a protocol that is used by the client. Why
shouldn't we support it?

IMO, returning an XML body in the 423 response is a good idea. It could
have a DAV:lockdiscovery element.

> jamsden> become complex. It will also reduce interoperability and

The spec is how we fix interoperability issues.

> fixed field in some property table points to a LOCK record stored

While this is true, we are talking about an error case. Personally, I
don't mind taking a few more cycles in an error case. Especially if there
is a possibility that the client will be needing that information anyhow.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Kevin Wiggen <[email-masked]>
Date: Thu, 03 Feb 2000 11:12:13 -0800

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: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, February 03, 2000 9:28 AM
To: [email-masked]
Subject: Re: 423 Locked

Subject:  Re: 423 Locked

Hi!

/Rickard

the
describe
specifies
redundant
AM