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

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.

With that said, I personally have no objection to requiring etag
support for PUT'able resources, but I am interested in hearing from
any server writers for whom requiring etag support would be problematic.

Cheers,
Geoff


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, November 27, 2002 9:55 PM
To: Webdav WG
Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg)



The issue of requiring ETags was brought up at the WG mtg, as one of the
remaining 2518 bis issues.  The discussion covered dynamic resources,
and a couple possible methods to generate ETags without too much pain
(using combinations of sequence numbers, timestamps, hashes of resource
names or content.).  Most interestingly, there was also a suggestion
that ETags could be required only for resources that can be PUT to.  

 

I think I'm satisfied with this compromise, because it's precisely in
the situation when a client is trying to PUT a resource body, that ETag
support is needed.  We've already discovered since 2518 was published
that locks aren't the only tool necessary to prevent lost updates - you
also need ETags.  For read-only resources Etags are nice-to-have in some
situations (like synchronization and caching) but there isn't the data
loss possibility.

 

Note that this would require that for any resource that supports PUT,
the server MUST return the ETag header on each GET request - because the
server can't tell when the GET request is received, whether the user
intends to try to do a PUT later or not.  

 

Comments?

 

Lisa