W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

RE: weak entity tags vs Apache moddav

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>
Message-ID: <JIEGINCHMLABHJBIGKBCMEDHFOAA.julian.reschke@gmx.de>

> 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
> > that two entities written within one second indeed can be substituted
> > 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


> 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.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 28 November 2002 07:47:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC