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

Re: PATCH Draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 26 Jun 2007 12:36:25 +0200
Message-ID: <4680EC29.5050007@gmx.de>
To: LMM@acm.org
CC: 'James M Snell' <jasnell@gmail.com>, 'Henrik Nordstrom' <henrik@henriknordstrom.net>, 'Lisa Dusseault' <ldusseault@commerce.net>, ietf-http-wg@w3.org

Larry Masinter wrote:
>> 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.
> Don't make this optional. The server shouldn't send the modified
> entity unless the client needs it, and the server has no way to
> determine whether the client needs it.  And the client can ask
> for it by doing a GET.
> Behavior should be predictable, and the fewer options you have,
> the better.


In the general case PATCH either fails with 4xx (Conflict) or succeeds. 
In the latter case, a client can always send a subsequent GET.

> I'm not entirely convinced that there is a demand for single client
> multiple server implementations of PATCH, or that it is viable
> without a MTI content-type for patching instructions. 

Yes. PATCH for atom entries is different from PATCH for arbitrary binary 
content, and that's different from Yaron's Web3S scenarios (I guess). I 
don't see how a single patch format would be helpful here...

> And if prior out-of-band agreement is needed, then you might as
> well just use POST with constructed URLs (http://site/path ->
> http://site/PATCHER/path for example), and you'd avoid the
> problem of expecting infrastructure that never heard of
> PATCH to quickly implement its POST-like caching rules.

Could you elaborate on this? If a POST to http://site/PATCHER/path 
affects the resource at http://site/path (for instance), how is a cache 
going to find out about that?

Best regards, Julian
Received on Tuesday, 26 June 2007 10:36:42 UTC

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