RE: FW: ETags again - basic question

Comments inline

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Tuesday, March 04, 2003 12:41 AM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV'
> Subject: 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). 

I absolutely agree with you, or rather, you agree with me, because
that's what I meant.  Servers that modify the entity (even due to
property changes from PROPPATCH) should change the Etag :)  

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

It is within the rules of 2616 to change the Etag when the entity does
not change. However, it is not expected behavior and causes
interoperability problems (screws the user if they're making changes).
Since WebDAV adds properties to resources, we need to explain how
properties affect Etags and how Etags are used in a distributed
authoring environment.

So anyway, we agree with each other again -- we can't forbid servers to
change an Etag when the entity doesn't change. All the spec can do is
recommend with SHOULD.

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

Right, but there are several cases where a very responsible locking
client might not have a lock at the point where the user wants to do a
PUT.
1.  The server doesn't support locks.
2.  The user decided to open the file for reading only. Maybe somebody
else had a lock initially, or the user didn't expect to go make changes,
or the user didn't have permissions to write when the first did the GET
and started editing.  Later, when the user instructs the client to save
changes, the client should be perfectly capable of seeing whether the
entity changed since the GET request -- using the Entity Tag.
3.  The client very responsibly got the lock, for a responsible period
like 1 hour. The client refreshed the lock as required, until the user
unplugged and walked onto the train with their laptop (hey, I do this
every night).  On the train, the user finally saves their changes.  Now
the client has a set of changes but no lock.  When the client gets a
network connection again, what does the client do?  It needs to do a PUT
with an If-Match header and an Etag.  
	(a) If the Etag matches, then the client can synchronize the
offline changes.  
	(b) If the Etag doesn't match because the entity changed, the
client has to find some way to error and ask the user what to do.
	(c) If the Etag doesn't match even though the entity has NOT
changed, the client either has to download the entire entity again and
compare for a literal match, or the client can screw the user by telling
them the resource body changed when in fact it didn't.  Yuck.

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

Unless this were part of the spec, I'm not sure clients would notice an
Etag on a PROPPATCH response.  Otherwise, that's a good idea.

This list has discussed in the past defining a new calculated property
to allow the client to tell when dead or unprotected properties have
changed -- a Property Tag or PTag, perhaps.  Has the day come for that
idea?

Lisa

Received on Tuesday, 4 March 2003 15:28:44 UTC