- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 28 Nov 2002 13:46:41 +0100
- To: "Roy T. Fielding" <fielding@apache.org>
- Cc: <ietf-http-wg@w3.org>
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]On > Behalf Of Roy T. Fielding > Sent: Thursday, November 28, 2002 12:41 AM > To: Julian Reschke > Cc: ietf-http-wg@w3.org > Subject: Re: weak entity tags vs Apache moddav > .. Roy, thanks for the feedback... > > Apache moddav indeed returns weak entity tags based on a filesystem > > timestamp. However, as far as I understand there's no guarantee whatsoever > > that two entities written within one second indeed can be substituted for > > each other with no significant change in semantics". So is this a bug or > > am I missing something important? > > No, it is just over-specification. It is impossible for an HTTP server > to know the semantics of a representation. However, if one representation Yes. > overwrites another such that both are valid responses to GET on the > same resource, then both are clearly intended to represent that resource. Sure. They are the same resource. But if the resource is modified multiple times within a clock interval, the server (Apache) will return the same weak entity tag, so user agents may not get the latest modification if they do a conditional GET. I'd say that in the case where another client actually did succeed to modifiy the resource twice (in the same clock interval) using PUT, this is wrong. > What the spec is trying to say is that a weak etag cannot be used to > test for byte equivalence of the representation, unlike a strong etag. > The HTTP components don't need to know why. OK. So I conclude that a generic authoring client (one that has no concept of semantically equivalent entities) MUST NOT use weak entitty tags to protect itself from lost updates upon PUT. Correct? > Apache etags are configurable, so the resource owner can determine what > is sufficient for differentiation based on the resource implementation. > We used to include the system inode by default, but that proved harmful > for server farms using rsync or raid mirrors. Interesting. -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 28 November 2002 07:47:14 UTC