Date: Fri, 21 Mar 1997 08:50:25 -0800 (PST) From: "Gregory J. Woodhouse" <firstname.lastname@example.org> To: Yaron Goland <email@example.com> cc: "'firstname.lastname@example.org'" <email@example.com>, Subject: RE: Partial Puts In-Reply-To: <11352BDEEB92CF119F3F00805F14F485026B721C@RED-44-MSG.dns.microsoft.com> Message-ID: <Pine.BSF.3.95.970321082848.6717Afirstname.lastname@example.org> I agree with Yaron that this is important functionality (though maybe not essential), and I believe it will only become more important. I don't see any way to consolidate insert and overwrite without overloading the byte range simply because we have no notation for byte range of length 0. I understand Larry's concern about the resource/entity distinction, but I fail to see why the fundamental issue is any different with partial PUTs (as opposed to ordinary PUTs). Partial PUTs are *much* more sensitive than ordinary PUTs to the current state of the resource. If the client has out of date information the end result will likely be garbled data. Therefore, I suggest a partial PUT include an optional (but strongly recommended) tag (in If-Match) and return failure if the tag is out of date. The client can then do a GET and try again with an updated partial PUT request. This may be preferable to a lock so long as the assumption that PUTs are relatively rare holds. I'm not sure if a new method is needed, we could just add appropriate request headers. Because of the potentially disastrous consequences of interpreting a partial PUT as an ordinary one, PEP negotiation of this functionality should be mandatory. --- email@example.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come up with a better one.