- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 29 Apr 2002 07:42:10 -0400
- To: w3c-dist-auth@w3c.org
From: Jason Crawford [mailto:ccjason@us.ibm.com] So if we want to avoid confusing clients that want to interoperate with those implementations, we probably can at most say that "PROPPATCH SHOULD NOT modify the etag or modification date". Sounds good. So then an ETAG change on a resource indicates to a client that the GET response *MIGHT* have changed. Hopefully we can make that a very strong SHOULD so that client checking for the "lost update problem" as part of a PUT isn't thrown off. I'm not sure that one can specify "degrees of SHOULD" (:-), but certainly one could mention the negative effect that violating this SHOULD has on caching clients. One thing I was concerned about is resources whose GET output changes often in hard to predict ways. For such live resources, the server might chose to change the ETAG continuously rather than try to track if the GET output has changed. If this is a red-herring, let me know. Yes, this is a red-herring (and even if it weren't, it is an HTTP-1.1 issue, not a WebDAV issue. Whether or not such a server choses to return a continuously updated ETAG, or no ETAG at all is just a server choice. Upon initial blush, I'd think that this means that "lost-update-checking" will always fail. But I think the answer to that is, you don't do a PUT against the live resource. I don't think we need to (or should) make such a statement. You could have a time-of-day resource that is live and continuously updated, but which allows a PUT to reset the time. You of course wouldn't use an If-Match etag with such an update request. You should do your PUT/PROPPATCH requests against source resources because they don't have this behavior. That will certainly be the common case, but I don't see that we have to say anything to that effect. Cheers, Geoff
Received on Monday, 29 April 2002 07:42:56 UTC