-----Original Message----- > From: Thierry Boileau [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 4:41 PM > To: discuss@restlet.tigris.org > Subject: Re: 404 from getRepresentation/handleGet? [. . .] > > I hope this will help you, > Thierry Boileau > p.s.: DELETE method does not return 404 according to the HTTP rfc: > "A successful response SHOULD be 200 (OK) if the response includes an entity describing the > status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the > action has been enacted but the response does not include an entity."
This is only true for successful DELETE requests. >From section 10.4 Client Error 4xx in rfc 2616: "... These status codes are applicable to any request method." A DELETE may, in fact, result in a response with 404 status. Consider the difference between 404 and 410. If a server is able to make the determination needed to return a 410 in response to a delete, then I would expect that it would probably want to return a 404 for those resources where it knows the resource is not permanently gone. It also seems reasonable to expect that it might want to return a 404 to indicate that a delete is being attempted on a resource that never existed in the first place. Also consider that some application protocols use DELETE as part of larger interaction where responding with a 2xx for a delete on an object that never existed in the first place would cause the overall interaction to complete erroneously. HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-01.html) uses DELETE on a message exchange resource to allow the client to signal to the server that it believes it has finished sending a message. If the server responded with a 200 for a non-existant exchange resource, it would be erroneously confirming that the message transfer was complete when in fact, the server has no knowledge of the message transfer being referred to. --Chuck
