Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 25 Feb 2003 17:07:10 -0800

Geoff said:

"Just one comment on the statement "we've already discovered since
2518 was published that locks aren't the only tool required to
prevent lost updates".  I disagree ... locks are sufficient to
prevent lost updates.  If a client decides not to use the locking
protocol correctly (i.e. by updating a resource for which it does
not have a valid lock), then of course something additional is 
required, but for a client that uses the locking protocol properly,
locks are the only tool required to prevent lost updates."

This was back in November but I have so far failed to respond. 

Locks never did solve the "lost update" problem, precisely.  (Etags
alone are sufficient to prevent a user from overwriting another users
changes.) Locks solve the "aggravated user" problem, which is when I've
been working for six hours on a document, and when I try to save it to
the server the server tells me somebody else made changes and do I want
to overwrite those changes...

So I lock the file to prevent other people from making changes while I
work.  I get to reserve the file until I submit all my changes. I'm
never presented with a dialog saying "do you want to overwrite"...
Ideally, that is.

In reality, locks can be lost.  The most common situation is probably
when the client goes offline accidentally during an editing session.
Users and client applications have no control over wireless, routers,
power -- failures that can prevent the client from renewing a lock.

So let's say you've lost your lock.  The user has been editing while the
lock existed, and they already made changes. When the client manages to
reconnect to try to save, the lock is gone.  Well, there are two
situations:
 (1) The file changed while it was unlocked.  That sucks, there's no
choice but to prompt the user to find out what they want to do.
 (2) The file did *not* change while it was unlocked.  Cool. Without
bothering the user with difficult and annoying questions, the client can
simply relock the file and save changes. 

Since (2) is much more common than one, and much more pleasant, the
client would like to know when (2) is the case.  Etags would solve this.
That's why I claimed that locks alone did not entirely solve the
lost-update problem.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 26 Feb 2003 02:27:14 +0100

Lisa,

I agree with the statement that etags are useful. Etags on their own are
useful. ETags in conjunction with locking are even more useful. I doubt
anybody disagrees.

The issue we've been debating recently whether this justifies to *require*
etags. My recent tests with IIS and Apache/Moddav show that upon a PUT, all
you get is a weak etag, which clearly demonstrates that it is non-trivial to
produce robust etags when your backend is a filesystem. So, IMHO, we really
*can't* require strong etags, and weak etags really do not help.

So yes, there must be a safe way for a client to discover the server's etag
support (supported live properties, allprop, propname and GET/HEAD behaviour
MUST match), but that's it.

If a client doesn't want to communicate with a resource that doesn't provide
strong etags, it certainly can (and should be able) to do so. I think that's
all RFC2518bis should say.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 25 Feb 2003 18:37:47 -0800

It's still possible to make a stronger statement about Etag support in
2518bis.  Servers that are compliant with that, whatever RFC number it
will be (maybe '4???'? )  must support strong Etags. Servers that are
compliant with RFC2518 don't need to.

I'm guessing Some clients will interoperate against both RFC2518 servers
and RFC2518bis servers since they're very similar. But eventually,
clients will be written that want the guarantees of "bis", including
Etag support, and these clients will prefer to interoperate with servers
supporting "bis".

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]] 
> Sent: Tuesday, February 25, 2003 5:27 PM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
> 
> 
> Lisa,
>

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 26 Feb 2003 09:23:22 +0100

Lisa,

> Etag support, and these clients will prefer to interoperate with servers

that would only be an option if this would be the only difference between
RFC2518 and RFC2518bis, and then if there would be no other future
extensions.

Clients can detect the presence of etags right now. Clients are free not to
author (PUT/PROPPATCH) resources without etags right now. I really don't see
how this change will help anybody.

- it *will* make IIS and Apache/moddav (and a some others) non-conformant

- it *may* encourage server developers to claim strong etag support,
although their etags aren't really strong -- *this* will cause harm because
it may cause undetected lost updates

We really should restrict the changes to those for which we do have
consensus (and these really are clarifications):

- servers SHOULD support etags on authorable resources

- clients MUST be able to reliably detect etag support for a resource

- also add language that describes why locks may not prevent lost updates
(and therefore why strong etags are so desirable)

Julian