- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Sep 2002 11:51:48 +0200
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
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