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

Received on Wednesday, 27 November 2002 21:54:59 UTC