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

Re: HTTP If-* headers, etags

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 29 Apr 2002 09:28:35 +0200
Cc: w3c-dist-auth@w3c.org
To: "Jason Crawford" <ccjason@us.ibm.com>
Message-Id: <B71E0362-5B42-11D6-BBE9-00039384827E@greenbytes.de>

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.

Received on Monday, 29 April 2002 03:29:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:25 UTC