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

Re: PATCH vs PUT w/Content-Range

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 29 Apr 2004 09:38:43 -0700
Message-Id: <AD570438-99FB-11D8-8BCF-000A95B2BB72@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>, Jim Luther <luther.j@apple.com>
To: Alex Rousskov <rousskov@measurement-factory.com>

Updates should be atomic -- the entire patch should be applied or 
entirely failed.  I will make that explicit.  Thanks!


On Apr 29, 2004, at 9:32 AM, Alex Rousskov wrote:

> On Thu, 29 Apr 2004, Jim Luther wrote:
>> I like the PATCH proposal because it provides clients with:
>> 1 - The ability to change the size of a resource independent or in
>> addition to changing the data. PUT doesn't do this unless you change
>> the current meaning of the byte-content-range-spec passed in a
>> Content-Range header so that */100 means "set the length of the
>> resource to 100 -- truncate the resource if its current length is more
>> than 100, zero extend the resource if its current length is less than
>> 100".
> How does PATCH proposal allow to separate data from its size?
> I was always thinking that in HTTP world the "size of the resource"
> and "size of [resource] data" are always the same. That is, "size" is
> not a property that can be changed without changing resource
> content/data. Can you clarify why would you want to separate the two
> concepts and would "zero" definition depend on content type or patch
> format?
>> 2 - The ability to change multiple ranges [...] with a single
>> request.
> Multi-hunk patches are indeed very useful to support atomic updates.
> draft-dusseault-http-patch-01 does not seem to have error codes
> related to situations where some of the patch hunks failed while
> others succeeded. Are all updates assumed to be atomic (i.e., all or
> nothing)? Should this assumption be made explicit? Sorry if I missed
> it in the draft.
> Thanks,
> Alex.
Received on Thursday, 29 April 2004 12:39:35 UTC

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