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:50:32 -0400
Message-ID: <523B1D48.6020500@andrew.cmu.edu>
To: Julian Reschke <julian.reschke@gmx.de>
CC: WebDAV <w3c-dist-auth@w3.org>
On 09/19/2013 11:43 AM, Julian Reschke wrote:
> On 2013-09-19 17:32, Ken Murchison wrote:
>> 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 could, but then a 200 with text/plain "Success" is a valid HTTP 
> response message, and fully self-descriptive. A client that breaks for 
> it is just a broken client, no matter what it asked for.
> We should resist the temptation to over-constrain things when HTTP 
> already gives the right answer.
>>> 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?
> I would avoid that. Don't profile HTTP when you don't have to.

OK.  How about something like this:

"... the server SHOULD return a200 (OK)response, preferably with an 
empty (zero-length) message body, ..."

This suggests an empty body, but doesn't require it.

Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Thursday, 19 September 2013 15:51:07 UTC

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