RE: FW: ETags again - basic question

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

Yes.

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

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

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 4 March 2003 03:41:14 UTC