RE: Locks and Moves

  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Kevin Wiggen
  Sent: Tuesday, May 18, 1999 1:35 PM
  To: w3c-dist-auth@w3.org
  Subject: Locks and Moves


  Sorry if this is answered somewhere, I couldn't find it...

  1) Section 8.10.4 "If the lock cannot be granted to all resources, a 409
(Conflict) status code MUST be returned with a response entity body
containing a multistatus XML element describing which resource(s) prevented
the lock from being granted."

    Then in example 8.10.10, a LOCK fails but gives a 207 response code in
the header.  What is the proper response code??
Good catch!  I think the proper response code is a 207, simply because this
is the only case where a 409 might have a body, and if you're adding WebDAV
support to an existing client library, it might be difficult to add
multistatus XML support for 409.  But, truth be told, 409 makes some sense
here, so I could be swayed. Jim Amsden -- how does DAV4J implement this?
  2)  If a more than one user has a share lock on a resource, they can all
WRITE to it, but can they DELETE it???  If resouce /C/B exists, and user FOO
and user BAR both have their own shared lock of /C/B, what happends if FOO
issues a DELETE?  Will the DELETE succeed thus removing the share lock FOO
AND BAR have on /C/B (but possibly leaving the lock on /C if /C/B was part
of a depth=INFINITY lock), or will the DELETE fail??
The intent of the spec. is the DELETE will succeed. We felt that people
using shared locks would be in close contact using out-of-band
communications paths, and hence someone wouldn't delete a resource unless
they discussed it first with their collaborators.
  3)  During a COPY or MOVE, if the file/directory exists, and the overwrite
flag = Y.  What happends if the DELETE portion fails??  Should the MOVE/COPY
fail giving the errors for the DELETE, or should the server still try to do
the MOVE/COPY to the location where the DELETE failed??  And what is the
proper response status (and XML) to return to the client in this case?
Another good catch. It should respond with the errors for delete, since
these are the conditions which would need to be removed by the client for
the operation to proceed.  This is certainly unclear in the spec.

I've added 1) and 3) to the issues list.

- Jim