- From: Kevin Wiggen <wiggs@wiggenout.com>
- Date: Thu, 03 Feb 2000 11:12:13 -0800
- To: jamsden@us.ibm.com, w3c-dist-auth@w3.org
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