- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 25 Mar 1997 13:54:02 -0800
- To: DAV Discussion <davdisc@microsoft.com>
I have written the following new partial PUT proposal based on the feedback I have received. Yaron 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 Implemented." 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