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.3.1 : Wednesday, 7 January 2015 15:01:39 UTC