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: Mark Baker <distobj@acm.org>
Date: Wed, 1 Aug 2007 00:26:19 -0400
Message-ID: <e9dffd640707312126x7ff4ce69weab46d82837e02ad@mail.gmail.com>
To: "Lisa Dusseault" <lisa@osafoundation.org>
Cc: ietf-http-wg@w3.org

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.

>    Would a client
> that cached the body of a 200 OK response in response to a GET behave
> correctly if it cached the body regardless of whether there was a
> Content-Location header?  According to my reading of 2616, the
> Content-Location header might or might not be there if the response
> contains a representation of the resource.

GET's different because it is requesting that the response body
include a representation of the resource identified by the
Request-URI.  The meaning of the response body is predetermined.

>
>
> > Are you aware of any software
> > which behaves this way?
>
> No, because we don't have PATCH clients implemented yet.

How about for PUT and POST?

> > The normal meaning from 2616 seems to be "the request was successful,
> > here's some data".  I don't see any reason to be more specific than
> > that.
>
> The 200 OK response for GET is certainly more specific than that --
> the data has a specific context, address and cache behavior
> intended.  That's what I'm driving at for PATCH.

GET is certainly different.  Indeed, GET responses are not
self-descriptive precisely because the response body has a fixed
meaning, but that fact isn't indicated in the message.  I think PUT
and POST make more appropriate role models for PATCH though.  Heck,
PATCH is just an optimized PUT.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Wednesday, 1 August 2007 04:26:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT