Message-ID: <11352BDEEB92CF119F3F00805F14F485026B722A@RED-44-MSG.dns.microsoft.com> From: Yaron Goland <email@example.com> To: "'Gregory J. Woodhouse'" <firstname.lastname@example.org> Cc: "'email@example.com'" <firstname.lastname@example.org>, Subject: RE: Partial Puts Date: Fri, 21 Mar 1997 12:04:22 -0800 Gregory, given this post and my response to Larry's original post, can I assume we are in violate agreement about how to proceed with partial PUT? Yaron > -----Original Message----- > From: Gregory J. Woodhouse [SMTP:email@example.com] > Sent: Friday, March 21, 1997 8:50 AM > To: Yaron Goland > Cc: 'firstname.lastname@example.org'; email@example.com > Subject: RE: Partial Puts > > 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. > > > --- > firstname.lastname@example.org / http://www.wnetc.com/home.html > If you're going to reinvent the wheel, at least try to come > up with a better one.