- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 15 Sep 2004 14:16:56 +0200
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- CC: webdav <w3c-dist-auth@w3.org>, "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
Geoffrey M Clemm wrote: > > Good catch, Girish! > > RFC-2518bis team: Please add this to the list of editorial issues > for 2518. > > These two sentences in 8.6 (in 8.7 of 2518bis) should be deleted. > The first sentence is wrong, because 204 is not an error, and so > there is no such thing as a "204 (No Content) error". > The second sentence is wrong, because 204 (No Content) is not > the "default success code". > > Cheers, > Geoff +1 > Girish wrote on 09/15/2004 02:58:50 AM: > > At the end of section 8.6 (DELETE), there is a statement which > > states that 204 should not be included in a 207. > > "Additionally 204 (No Content) errors SHOULD NOT be returned in > > the 207 (Multi-Status).The reason for this prohibition is that > > 204 (No Content) is the default success code." > > It was this particular phrase which confused me. > > > Girish wrote on 09/14/2004 10:42:32 AM: > > > Can a successful DELETE (in my case, deletion of a version-history) > > > return some content (some href, for example) to the client? > > > RFC 2158 states that 204 (no content) is the default success code > > > for DELETE. I was wondering if there are special deltaV semantics. Yet, why would you *want* to send a response body upon DELETE? Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 15 September 2004 12:17:31 UTC