Subject: RE: FW: ETags again - basic question

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 2 Mar 2003 08:47:49 -0500

Note that some file-based implementations store the dead properties as part
of the file content and use the file content information to compute the
etag.  So an interoperable client can only make the following assumptions:

- If the resource content changes, the strong etag MUST change.
- If the properties change, the strong etag MAY change.

Cheers,
Geoff 

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Saturday, March 01, 2003 5:15 PM
To: Jim Whitehead
Cc: WebDAV
Subject: Re: FW: ETags again - basic question

Okay, I'll take a stab at this one...

> When does an (strong) etag of a resource change?
>
> 1) when the content of a resource has changed (e.g. after a PUT)
> 2) when one of the properties has changed (e.g. after a PROPPATCH)
> 3) in both cases 1) and 2)

I think the answer is whenever the GET response changes.  So for most
resources the answer is almost always (1), not (2) or (3).   If you have a
live
resource that is dependent on other info, the answer might vary.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 3 Mar 2003 16:23:53 -0800

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.

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

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.

Lisa

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Clemm, Geoff
> Sent: Sunday, March 02, 2003 5:48 AM
> To: WebDAV
> Subject: RE: FW: ETags again - basic question
> 
> 
>

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 03 Mar 2003 16:46:37 -0800

Can we include language to this effect in the specification? To do 
otherwise is to invite interop issues. I haven't read the latest draft 
closely, my apologies if you've already inserted the appropriate 
verbiage somewhere. I think this is an important issue that both client 
and server implementers need to understand fully.

Cheers,
Elias

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 09:40:37 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, March 04, 2003 1:24 AM
> To: 'Clemm, Geoff'; 'WebDAV'

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.

> again unnecessarily. Perf problem only.

Yes.

> confuse the user if somebody else changed the properties and makes their

So they'd better take a lock as well.

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

> saying the content is actually different just because the ETag is

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 4 Mar 2003 12:28:43 -0800

Comments inline

> From: Julian Reschke [mailto:[email-masked]] 
> Sent: Tuesday, March 04, 2003 12:41 AM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV'
> 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

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.

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

> optionally return a new entity tag after PROPPATCH (just like 

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

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 22:24:37 +0100

> Sent: Tuesday, March 04, 2003 9:29 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV'
> ...

Agreed.

> Etag on a PROPPATCH response.  Otherwise, that's a good idea.

So we may want to add this to RFC2518bis (if a PROPPATCH modifies the etag,
it SHOULD be returned in a PROPPATCH response).

> changed -- a Property Tag or PTag, perhaps.  Has the day come for that

I always liked that for symmetry reasons. But how does this help with the
original problem?

Julian