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: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 31 Jul 2007 10:43:17 -0700
Message-Id: <A247D5FD-F1DE-4BF8-BC74-8CBB77D06D98@osafoundation.org>
Cc: "James M Snell" <jasnell@gmail.com>, jasnell@us.ibm.com, ietf-http-wg@w3.org
To: Mark Baker <distobj@acm.org>

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?    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.

> Are you aware of any software
> which behaves this way?

No, because we don't have PATCH clients implemented yet.

> 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.

Received on Tuesday, 31 July 2007 17:43:34 UTC

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