- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Sat, 27 Apr 2002 11:11:47 -0400
- To: "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: w3c-dist-auth@w3c.org
<< 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. 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. 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. You should do your PUT/PROPPATCH requests against source resources because they don't have this behavior. Does everyone agree on that? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Saturday, 27 April 2002 11:22:21 UTC