Re: Fwd: I-D Action: draft-murchison-webdav-prefer-05.txt
Ken Murchison <[email protected]> Thu, 19 Sep 2013 11:50:32 -0400
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Organization | Carnegie Mellon University |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------090801000305080705020109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------090801000305080705020109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/19/2013 11:43 AM, Julian Reschke
wrote:<br>
</div>
<blockquote cite="mid:[email protected]" type="cite">On
2013-09-19 17:32, Ken Murchison wrote:
<br>
<blockquote type="cite">On 09/19/2013 10:44 AM, Julian Reschke
wrote:
<br>
<blockquote type="cite">On 2013-09-19 16:05, Ken Murchison
wrote:
<br>
<blockquote type="cite">...
<br>
<blockquote type="cite">
<blockquote type="cite">The argument here is that we don't
want the client to have to parse a
<br>
body if the request is successful. Do you recommend
that we
<br>
specify 204
<br>
instead?
<br>
</blockquote>
<br>
The client doesn't need to parse the body, even if it's
non empty.
<br>
</blockquote>
<br>
This is true, but including anything in the body defeats the
purpose of
<br>
return=minimal. The 2xx response code tells the client that
all
<br>
instructions were performed successfully so there is no need
for any
<br>
other verbiage.
<br>
...
<br>
</blockquote>
<br>
I agree there's no need. I just wonder how strong the
requirement no
<br>
to return anything is. I want to avoid a situation where
clients blow
<br>
up just because they get a tiny status message.
<br>
</blockquote>
<br>
Playing devil's advocate here: If a client sends return=minimal
with a
<br>
PROPATCH or MKCOL/MKCALENDAR and can't handle the minimal
response, then
<br>
its a bad client. If it can't handle a minimal success response
is MUST
<br>
NOT send return=minimal. Likewise, if a server can't properly
send a
<br>
minimal response, then it MUST NOT return Preference-Applied.
<br>
<br>
The more I think about this, I'm wondering why we can't specify
that
<br>
return=minimal requires an empty body upon success, or just
specify that
<br>
the server return 204. If either a client or server can't
implement it
<br>
this way, then it is free to not use or ignore the preference.
<br>
</blockquote>
<br>
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.
<br>
<br>
We should resist the temptation to over-constrain things when HTTP
already gives the right answer.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Just state that the response can be any
suitable success message (200,
<br>
201, 204), and - for 200/201 - a response payload (a) is not
needed
<br>
and (b) does not need to be processed.
<br>
</blockquote>
<br>
I'd really like to nail this down, so there isn't a any variance
in
<br>
responses. If we can't specify empty body, can we just go with
204?
<br>
</blockquote>
<br>
I would avoid that. Don't profile HTTP when you don't have to.
<br>
<br>
</blockquote>
<br>
<br>
OK. How about something like this:<br>
<br>
"... the server SHOULD return a<cite> 200 (OK)</cite><cite
title="NONE"></cite> response, preferably with an empty
(zero-length) message body, ..."<br>
<br>
This suggests an empty body, but doesn't require it.<br>
<pre class="moz-signature" cols="72">--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
</pre>
</body>
</html>
--------------090801000305080705020109--