- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 29 Apr 2002 09:28:35 +0200
- To: "Jason Crawford" <ccjason@us.ibm.com>
- Cc: w3c-dist-auth@w3c.org
Am Samstag den, 27. April 2002, um 17:11, schrieb Jason Crawford: > > << > 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. Fine with me. > 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. I think for continuously changing content, the server should not generate an ETag at all. If content changes more frequently than clock resolution (1 second), the server should send an Expires header with a date in the past. > 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. Such resources would most likely be read only, I agree. //Stefan
Received on Monday, 29 April 2002 03:29:04 UTC