W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2013

Re: Fwd: I-D Action: draft-murchison-webdav-prefer-05.txt

From: Ken Murchison <murch@andrew.cmu.edu>
Date: Thu, 19 Sep 2013 11:32:04 -0400
Message-ID: <523B18F4.5060801@andrew.cmu.edu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:45 UTC