RE: ETags, was: Issues from Interop/Interim WG Meeting

Some more thoughts on ETags:

1) Even for a server that *in general* supplies ETags, there may be some
special resources that can't have them. So requiring them won't work.
Example: a very common implementation for WebDAV ACL principal resources
will be a proxy resource that talks to a usermanagement back-end. These
resources may have content (for instance, a vCard entity body), but they
won't have an entity tag (because they are dynamically generated from a
remote object). This basically applies to all resources that are dynamically
created and not easily cached. So is a server that has GETtable, but
non-cacheable principal resources compliant to RFC2518bis?

2) It was said that lack of ETag is an interop problem. I can see why some
authoring clients would want to require that a resource that they are going
to modify has valid ETags. However, on a RFC2518-compliant server a client
can easily detect whether ETags are supported, and thus refuse to modify the
resource accordingly. This really isn't a problem -- it just means that a
particular client can't modify a particular resource, and the user can be
notified. However, it would be a much bigger problem if a server claims that
it has ETags, but they don't work properly. In this case, the user agent
will try to take advantage of ETag handling, and this may result in lost
updates, faulty cache contents and so on. So *this* is what the revision of
RFC2518 should say: if you can't provide proper ETags for a resource, it's
better that you *don't* try and thus let clients that rely on proper ETag
handling fail in a predictable way.

Julian

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

Received on Thursday, 19 September 2002 05:52:22 UTC