- From: Ken Murchison <murch@andrew.cmu.edu>
- Date: Thu, 19 Sep 2013 11:32:04 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: WebDAV <w3c-dist-auth@w3.org>
On 09/19/2013 10:44 AM, Julian Reschke wrote: > 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. Playing devil's advocate here: If a client sends return=minimal with a PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal response, then its a bad client. If it can't handle a minimal success response is MUST NOT send return=minimal. Likewise, if a server can't properly send a minimal response, then it MUST NOT return Preference-Applied. The more I think about this, I'm wondering why we can't specify that return=minimal requires an empty body upon success, or just specify that the server return 204. If either a client or server can't implement it this way, then it is free to not use or ignore the preference. >>> 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. I'd really like to nail this down, so there isn't a any variance in responses. If we can't specify empty body, can we just go with 204? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Received on Thursday, 19 September 2013 15:32:35 UTC