Subject: Q: does this use of 424 seem reasonable?

From: Greg Stein <[email-masked]>
Date: Wed, 31 May 2000 12:16:25 -0700 (PDT)

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/

---

From: Kevin Wiggen <[email-masked]>
Date: Wed, 31 May 2000 12:33:02 -0700

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Wednesday, May 31, 2000 12:16 PM
To: [email-masked]
Subject: Q: does this use of 424 seem reasonable?

Hi all...

Thanx,
-g

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 31 May 2000 17:58:25 -0400 (EDT)

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 <[email-masked]>

   Thanks,
   Kevin

   -----Original Message-----
   From: [email-masked]
   [mailto:[email-masked]]On Behalf Of Greg Stein
   Sent: Wednesday, May 31, 2000 12:16 PM
   To: [email-masked]
   Subject: Q: does this use of 424 seem reasonable?

   Hi all...

   Thanx,
   -g

---

From: Greg Stein <[email-masked]>
Date: Wed, 31 May 2000 15:22:24 -0700 (PDT)

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

---

From: Kevin Wiggen <[email-masked]>
Date: Wed, 31 May 2000 15:38:47 -0700

I am fine with the 424 as long as clients expect to see a XML body from a
Webdav server.  We NEED to have some way of informing the client why the
move/delete failed.

Again I don't care if its a new status or an existing one, I would just like
to make sure that an XML body (without internal 424's as this would be
possibly huge) can (and MUST) be returned to the client.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Wednesday, May 31, 2000 3:22 PM
To: [email-masked]
Subject: Re: does this use of 424 seem reasonable?

Cheers,
-g