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

Re: PATCH vs PUT w/Content-Range

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Thu, 29 Apr 2004 10:32:03 -0600 (MDT)
To: Jim Luther <luther.j@apple.com>, Lisa Dusseault <lisa@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>
Message-ID: <Pine.BSF.4.58.0404291012220.48149@measurement-factory.com>

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

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


Received on Thursday, 29 April 2004 12:32:40 UTC

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