W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: FW: ETags again - basic question

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 4 Mar 2003 09:40:37 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEEKGKAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 1:24 AM
> To: 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: FW: ETags again - basic question
> I strongly recommend servers to change Etag only when the entity
> changes. After all, it's the "Entity" tag.  Here are two to three
> practical reasons.

And I object again :-)

This is yet another issue where theory and reality (implementation practice)
collide. As Geoff noted, there are servers that store properties in the same
file entitiy, and thus both DAV:getlastmodified and DAV:getetag change when
dead properties change. Furthermore, there are servers that actually
*modify* the entity contents upon PROPPATCH (I've seen IIS do this for
Office files). All of these behaviours may be surprising, but *do* conform
to RFC2518 and RFC2616, and I don't think we can forbid them without taking
away a lot of implementation freedom.

> If the ETag changes when the properties change, then:
> 1.  Clients who have cached based on the ETag will download the file
> again unnecessarily. Perf problem only.


> 2.  Clients who are editing without a lock (including clients who lost
> their lock accidentally due to network conditions) must compare Etag to
> see if it's safe to upload their changes.  This edit will fail and
> confuse the user if somebody else changed the properties and makes their
> upload fail.

So they'd better take a lock as well.

> 3.  Clients who are editing with a lock might issue a PROPPATCH, then
> try to issue a PUT with an ETag validation. If the ETag has changed due
> to the PROPPATCH, then the client will be very confused whether or not
> the file can be overwritten. The lock still appears to be there, yet the
> ETag changed -- how did that happen?

That's indeed a problem. I think the correct way to handle this would be to
optionally return a new entity tag after PROPPATCH (just like PUT is doing

> Geoff's comments are perfectly correct for client implementors -- it's
> hard to predict how servers actually modify ETags. There's no rule
> saying the content is actually different just because the ETag is
> different.

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 03:41:14 UTC

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