Re: does this use of 424 seem reasonable?

Um. Including 424 into a 207 is legal (since it is only a SHOULD NOT), but
it means that I would have to generate a response for all 1000 children of
the collection that I'm trying to delete. Each resource would have to say
"sorry, I wasn't deleted due to a 424 (Failed Dependency)".

I'm seeking to return a single, top-level status that indicates the whole
thing failed.

424 seemed most appropriate (4xx meaning the client can fix it, and 424
meaning that it was caused by some other reason). A 409 (Conflict) would
also be fine, but I don't think it provides as much information (409 seems
to say "problem with <this> resource" while 424 says "problem with <that>
resource").

Kevin suggests creating a new 4xx status. I'm not sure that I want to go
that far :-). If the body is a problem, then I'll probably just leave out
a body. Although... I can't see how that would be a problem... I'm with
Geoff on this one -- how does a body in a 424 cause a problem?

Okay. Fine-tuning of the response aside, I also get the feeling that
nobody is going to pester me saying "you moron, it should be best effort."
I'm going to solidify the "single failure response" in mod_dav now, and
look for responses to this thread to find the right status code and body
contents.

Cheers,
-g

On Wed, 31 May 2000, Geoffrey M. Clemm wrote:
> 
> 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/
> 

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

Received on Wednesday, 31 May 2000 18:23:09 UTC