RE: does this use of 424 seem reasonable?

I think that not doing a best effort delete/move (copy should occur even if
its locked), is a very valid thing for a server to do.  In fact I would
argue that if MS could implement a "rollback" during the delete/move, we
would make these operations atomic.

Since this is true, I would like agree with Greg that a new status code
should be created that states the operation failed (do to locks,
permissions, etc) and the operation was rolled back.

Xythos would then return the new status code for a failed move/copy instead
of doing a best effort (along with mod_dav), and MS can return the
best-effort status for move/copy.

It has been our experience that a best effort delete/move is the WORST thing
to do to a user.  The XML returned should note ALL resources that are
stopping the move/delete and what the problem is (locks, permissions, etc),
so that the client can tell the user what is stopping the operation.

Thanks,
Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein
Sent: Wednesday, May 31, 2000 12:16 PM
To: w3c-dist-auth@w3.org
Subject: Q: does this use of 424 seem reasonable?


Hi all...

One more question: in the current mod_dav architecture, I am unable to do
a "best effort" delete/move/copy when a lock exists somewhere in the
affected resources. As a result, the only real option available is to fail
the entire request.

However, this would effectively mean returning a 207 (Multistatus) that
contains an entry for every single resource stating (in some way) that it
was not deleted/moved/copied.

I would much rather do the following:

*) return 424 (Failed Dependency)
*) include a body in the 424 response, which contains a DAV:multistatus
   element which refers to the locked resource


Does this seem reasonable?

Thanx,
-g

p.s. and no, fixing it to do best-effort is not an option

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

Received on Wednesday, 31 May 2000 15:35:58 UTC