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

On 2013-09-19 17:50, Ken Murchison wrote:
> 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.

I wouldn't rule out 204.

"The server SHOULD return a minimal success response, such as 200 (OK) 
(preferably with ...), or a 204 (No Content)."

Best regards, Julian

Received on Thursday, 19 September 2013 15:56:30 UTC