Re: PATCH vs PUT w/Content-Range

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 
sent:

	0xd1, 0xff, 0xd1, 0xff
	4
	249,0,0,100
	0

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