RE: does this use of 424 seem reasonable?

Argh.  Just in case anyone wonders what in the world I was
referring to by 528, I meant 2518 (which I guess makes me
both dyslexic and forgetful :-).

Cheers,
Geoff

-----Original Message-----
From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
Sent: Wednesday, May 31, 2000 5:58 PM
To: w3c-dist-auth@w3.org
Subject: Re: does this use of 424 seem reasonable?



I heartily concur that atomic delete behavior is far more well behaved
from a client's perspective, and should be supported whenever possible
(and will even be required in the presence of multiple bindings to a
resource).

Last time I suggested returning a body with a 4xx status indicating
what failed, JimW said this would cause a problem, but unfortunately
I never did get what that problem would be.  I hope JimW was wrong,
because otherwise I see no easy way to avoid running out of 4xx
status codes someday soon ...

Assuming it is a problem, an alternative marshalling would be to return
the 424's in a 207, since currently 528 says that 424's SHOULD NOT be
returned in 207's from a DELETE (so we should be able to use the
424 to mean what we want).

Cheers,
Geoff

   Date: Wed, 31 May 2000 12:33:02 -0700
   From: Kevin Wiggen <wiggs@wiggenout.com>


   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/