W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 1 Aug 2007 11:36:35 -0700
Message-Id: <B7F2ADB2-E18B-4662-AA55-14D43123E394@gbiv.com>
Cc: "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org
To: Mark Baker <distobj@acm.org>

On Jul 31, 2007, at 9:26 PM, Mark Baker wrote:
> On 7/31/07, Lisa Dusseault <lisa@osafoundation.org> wrote:
>> On Jul 31, 2007, at 9:59 AM, Mark Baker wrote:
>>> Hi Lisa,
>>> On 7/31/07, Lisa Dusseault <lisa@osafoundation.org> wrote:
>>>> If we allow the server to return arbitrary bodies in a 200 response
>>>> to a PATCH, we'll have to be very clear on how clients should  
>>>> handle
>>>> the returned information.  A caching or synching client might  
>>>> use the
>>>> body as the new representation of the resource regardless of what
>>>> headers appeared in the 200 response.
>>> That would be a broken client, AFAICT.
>> Interesting!  What's your basis for believing that?
> Just from the meaning of PATCH.  It's purpose is just to affect a
> state change on the server, and isn't requesting that anything
> specific be returned in the response, just like PUT and POST.
> Therefore there's no reason to limit the meaning of what might be
> returned.

That's backwards.  If we had the choice of doing so at the time, PUT
would have been defined such that 200 responses would be the same as
if the method had been GET (i.e., return the resulting representation
after the PUT was applied) and 204 would be success without a body.
The only reason we did not define it that way is because some of the
existing, deployed implementations were inconsistent (because they
were deployed before 204 was available).

We don't have that problem today with PATCH, AFAIK.  There is no
reason not to define a 200 response to PATCH as being the same as
the representation that would have been received in a GET response
after the patch has been successfully applied.  Remember, we aren't
forcing the server to return 200 -- the server can choose which
status is returned.

Received on Wednesday, 1 August 2007 18:36:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC