- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Sep 2013 16:44:44 +0200
- To: Ken Murchison <murch@andrew.cmu.edu>
- CC: WebDAV <w3c-dist-auth@w3.org>
On 2013-09-19 16:05, Ken Murchison wrote: > ... >>> The argument here is that we don't want the client to have to parse a >>> body if the request is successful. Do you recommend that we specify 204 >>> instead? >> >> The client doesn't need to parse the body, even if it's non empty. > > This is true, but including anything in the body defeats the purpose of > return=minimal. The 2xx response code tells the client that all > instructions were performed successfully so there is no need for any > other verbiage. > ... I agree there's no need. I just wonder how strong the requirement no to return anything is. I want to avoid a situation where clients blow up just because they get a tiny status message. >> We can allow 204 as well; but we should stick with standard HTTP; and >> over there it's not uncommon that servers send a short text/plain or >> text/html result, even if it's not needed. > > OK. How would you specify the use of return=minimal with PROPPATCH and > MKCOL/MKCALENDAR, or do you think that it can't be applied to these > methods in the real world? Just state that the response can be any suitable success message (200, 201, 204), and - for 200/201 - a response payload (a) is not needed and (b) does not need to be processed. > ... Best regards, Julian
Received on Thursday, 19 September 2013 14:45:24 UTC