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

Re: PATCH vs PUT w/Content-Range

From: Jim Luther <luther.j@apple.com>
Date: Thu, 29 Apr 2004 12:49:57 -0500
Message-Id: <A0FBB84A-9A05-11D8-A729-000A9577847A@apple.com>
To: HTTP working group <ietf-http-wg@w3.org>

On Apr 29, 2004, at 11: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?

I meant that you could change the size of a resource without resending 
its existing content. For example, to truncate a resource to just the 
first 100 bytes of its current content, this gdiff command could be 

	0xd1, 0xff, 0xd1, 0xff

Extending a resource without resending its existing content can be 
accomplished with a gdiff copy command (to copy the existing resource 
content) followed by a data command with the new data to be appended.

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

Yes, I agree that updates should be atomic. On many current HTTP 
servers PUT is not atomic, and so a GET during an in-progress PUT will 
return just the portion of the resource already sent to the server.
Received on Thursday, 29 April 2004 13:50:40 UTC

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