- From: <jamsden@us.ibm.com>
- Date: Thu, 27 Jan 2000 17:48:49 -0500
- To: w3c-dist-auth@w3.org
That was my interpretation. bill@carpenter.ORG (WJCarpenter)@w3.org on 01/27/2000 02:45:51 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: is DELETE "best effort"? RFC-2518 doesn't come right out and say so, but I think it implies that a DELETE on a collection is on a "best effort" basis, where you can deduce what got DELETEd versus what didn't (and why) from a possible multistatus response. Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals and /zoo/birds. Suppose there is a problem with the DELETE of /zoo/mammals (it's locked by my corporate rival, Snidely Whiplash). Should the server, having discovered this, go ahead and attempt a DELETE of /zoo/birds? Section 8.6.2 says that if you can't DELETE a resource, you shouldn't DELETE its ancestors (for the sake of namespace consistency). It is silent on what you should do about the resource's siblings, though (the example in 8.6.2 isn't bushy enough to show it). There is a hint that some of the DELETEs may be allowed to succeed while others fail in that 204 response codes are to be omitted from the multistatus because they are the default success code. Is DELETE intended to be "best effort"? -- bill@carpenter.ORG (WJCarpenter) PGP bill@bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Received on Thursday, 27 January 2000 18:00:29 UTC