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: Thu, 28 Jun 2007 10:47:59 -0700
Message-ID: <4683F44F.2080200@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: LMM@acm.org, 'Henrik Nordstrom' <henrik@henriknordstrom.net>, 'Lisa Dusseault' <ldusseault@commerce.net>, ietf-http-wg@w3.org



Julian Reschke wrote:
>>[snip[
>> 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.
> 
> +1.
> 
> In the general case PATCH either fails with 4xx (Conflict) or succeeds.
> In the latter case, a client can always send a subsequent GET.
> 

The only challenge with this is that the whole point of returning the
entity in the response is to verify that the resource was patched
successfully.  If the resource is modified between the time the PATCH
response is received and a subsequent GET is issued, then verifying the
result becomes problematic.  Using Etags we can obviously detect the
subsequent change, but it's harder to verify that our specific change
was applied correctly.  For byte/character based deltas, this is not so
much of a problem.  For structural deltas it can be a significant problem.

- James
Received on Thursday, 28 June 2007 17:48:11 GMT

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