W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

New Partial Put

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 25 Mar 1997 13:54:02 -0800
Message-ID: <11352BDEEB92CF119F3F00805F14F485026B72B0@RED-44-MSG.dns.microsoft.com>
To: DAV Discussion <davdisc@microsoft.com>
I have written the following new partial PUT proposal based on the
feedback I have received.

1	Partial PUTs

1.1	Problem Description

Clients who make small changes to resources do not wish to have to
upload an entire entity. As such, some sort of partial write capability
is needed.

1.2	Proposal

Until now the use of the range header in a PUT has not been allowed
because the semantics of this action have not been clearly defined. I
propose defining those semantics exactly.

A range header in a PUT should be an overwrite operation. An overwrite
indicates that the request body should overwrite whatever exists in the
range specified by the range header. The entity associated with the
range header MUST be equal in length to the range specified in the range
header. If not the server MUST ignore the request. If the range
specifies a zero length entity, then the request MUST be ignored. An
over write may have a range that is beyond the end of the resource, thus
extending the length of the resource. If the goal is only to append then
the range may begin exactly one range unit beyond the end of the
resource.  In the case of bytes and pure appends, the beginning of the
range should specify exactly one byte beyond the end of the resource. 

If the content-type of the request body is multipart/byte-ranges then
the previous behavior may be generalized across the multipart entries.
If a member of the multipart fails then the server may abort the rest of
the entries. If at least one entry succeeds then a 207 "Partial Success"
result must be returned with a web collection explaining the results.

There are resources where the use of range and PUT do not produce a
sensible result. In such a case the resource should return a 501 "Not

1.3	Discussion

Clients can not depend upon arbitrary servers respecting this
functionality. As such the client should use the DAV feature discovery
tokens defined in a later position paper or should use a PEP header.
Received on Wednesday, 26 March 1997 00:33:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC