RE: "Lost Updates" still persist...

I think an implementation note would be appropriate. I would suggest adding
a new section in the section on PUT entitled "PUTs, GETs, E-Tags and Locks".
The text would read as follows:

It is an error for a client to assume that the state of a resource will not
change between the time a GET and then a PUT are executed.  When that
assumption is made it is possible for the "lost update" problem, defined
previously, to occur.  The lock mechanism defined in this document provides
tools to control what sort of state changes are allowed to happen between
the execution of methods.  However not all servers support locks and not all
clients are capable of asking for a lock.  In the case where a client does
not have the appropriate lock available and wishes to ensure that they will
not suffer from the lost update problem then the client should use the
if-match header on their PUT request.

		Yaron

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Monday, February 16, 1998 11:49 PM
> To:	Yaron Goland; 'Sanford L. Barr'; ejw@ics.uci.edu; 'WEBDAV WG';
> jdavis@parc.xerox.com
> Subject:	Re: "Lost Updates" still persist...
> 
> 
> >If someone writes a buggy client that is so unbelievably stupid that it
> >assumes that resources do not change over time then might I respectfully
> >suggest that the market will very quickly make the product a failure. 
> >
> >This is not an issue of a protocol requirement, this is an issue of
> common
> >sense. 
> >
> >Alas, one can not require common sense.
> 
> 
> It is common to require that services protect themselves against clients
> that misbehave.
> Even though misbehavior might be against "common sense" from some
> perspectives,
> there are so many applications for an un-guarded PUT that it's not against
> "common sense"
> to believe that a client might be capable of doing a PUT without a lock,
> and that some
> user might misapply this operation to a server that otherwise had a
> perfectly good
> locking mechanism.
> 
> And it is also the case that products that don't guard against such
> misbehavior
> might STILL be a success in the marketplace.
> 
> All in all, I think there's a place for some discussion of the issues in
> the Webdav spec,
> even if it is an implementation note. Implementation notes have the
> advantage of not
> forming requirements for 'common sense', but at least in making it more
> common.
> 
> Regards,
> 
> Larry
>

Received on Wednesday, 18 February 1998 00:02:01 UTC