W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

RE: HTTP If-* headers, etags

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
Message-ID: <OF7E3EAF31.37AAF839-ON85256BA7.0069F7F5@pok.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.

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT