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

Re: PATCH Draft

From: James M Snell <jasnell@gmail.com>
Date: Mon, 25 Jun 2007 22:54:34 -0700
Message-ID: <4680AA1A.1070703@gmail.com>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: Lisa Dusseault <ldusseault@commerce.net>, ietf-http-wg@w3.org

Henrik Nordstrom wrote:
> [snip]
>> That should be fine.  I wonder if it's worth the extra variation to  
>> allow the server to carry the entire modified entry.  In some cases  
>> that would remove the whole point of supporting PATCH (allowing  
>> authoring of large files without constant uploading and downloading  
>> of entire file) so returning the body at least has to be optional.
> The draft already talks about returning the modified entity, with an 200
> example carrying it..
> If the server do not want to return the modified entity then it can
> return a 204.

Yep. Returning the complete entity body is optional in the draft and is
likely only going to be useful when using structural deltas where things
like MD5 hashes are inadequate for determining the success of the delta.

> The only question is if there is a need to have the server return status
> messages on a successful PATCH other than the entity itself, or the
> actual resulting diff if some server-side processing was done. If 200
> returns the modified entity then what to use if the server do not want
> to return the modified entity but instead need to return status messages
> about the successful PATCH operation or perhaps a diff?

Good point. We would need some way of signaling that the returned entity
is not the modified entity but itself a delta.  Will have to think about
that a bit more.

> For as long as 200 returns the modified entity there is no reason not to
> allow it to be cached.


>> Accept is a request header.  I assumed that it would be viewed in bad  
>> taste to use it as a response header.  It might also in the long run  
>> be confusing -- the server might accept certain diff formats for  
>> PATCH, but accept other inputs for other purposes.
> Agreed.
> But a more expressive name than Accept-<method> should probably be used
> then. If not there is a risk for a name collision if/when other Accept-X
> headers is added or new methods with similar names..

Hmm... I'm absolutely terrible at these kinds of discussions mainly
because I tend not to care what the heck we call it as long as it does
the job ;-).

- James
Received on Tuesday, 26 June 2007 05:54:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC