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

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 27 Nov 2002 18:54:56 -0800

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

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 28 Nov 2002 09:58:43 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Thursday, November 28, 2002 3:55 AM
> To: Webdav WG
> Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>

This makes sort of sense. However, I still don't see why this should be a
requirement. A client that requires entity tags can trivially find out
whether a resource supports them. If the resource doesn't support entity
tags, but the client needs them, don't attempt the operation.

I do agree with the earlier consensus that servers must be consistent in
what they say about etag support (per ressource), notably that DAV:getetag
must be present as property if and only iff HEAD/GET return the etag as well
(but this is just a clarification, not a new requirement).

> support is needed.  We've already discovered since 2518 was published

Actually, that requires *strong* entitity tags as opposed to weak entitity
tags, right? If you make strong etags a requirement, Apache moddav (when
talking to a fs backend) becomes non-compliant. Have you considered that?

> ...

Julian

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