Subject: RE: HTTP If-* headers

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 26 Apr 2002 12:41:46 -0400

Whenever the topic has come up in the past, it has always
become clear that there will always be some live properties
that will change without updating the DAV:getlastmodified
or DAV:getetag values, that some implementations will update
these values when dead properties (and certain live properties)
change, and that other implementations will never update these
values for any property change.

So there is little useful we can say about the relationship
between property values and the If-* headers.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:[email-masked]]
Sent: Friday, April 26, 2002 12:19 PM
To: [email-masked]
Subject: HTTP If-* headers

You saw this coming, didn't you? ;)

The HTTP If-* header family, namely

If-Match, If-None-Match, If-Modified-Since,
If-Unmodified-Since and If-Range

are described in rfc2616 as they apply to
GET, HEAD and PUT.

But what about the WebDAV methods? I think we need
to clarify and put an advisory in an updated rfc2518.

Easy things first: If-Range seems only to make sense
with GET. So we could exclude it from discussions of
other methods.

The other four, IMO, should be honoured on DELETE,
COPY, MOVE, LOCK and UNLOCK.

But what about PROPFIND? For the If-* headers to make
sense with PROPFIND, a client would rely on the
assumption that DAV:getlastmodified and DAV:getetag
change when properties are changed (either by PROPPATCH
or as a side-effect on live properties from other
methods.)

Would the burden on the server (to update etag/lastmodified)
justify the benefit? I rather doubt that, but would like
to hear the opinion of the excellent audience on this list.

//Stefan

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 26 Apr 2002 19:06:29 +0200

> values for any property change.

That is the current state of affairs, yes.

> between property values and the If-* headers.

Hmm. I think it would be useful to say that ETags should only
change on content modifications. In my understanding HTTP
caches are encouraged by HTTP/1.1 to validate on ETags.
WebDAV enabled servers could improve caching if PROPPATCH
and friends would not change ETags.

So, a recommendation in a future version of 2518 makes sense,
don't you think?

//Stefan

---

From: "Jason Crawford" <[email-masked]>
Date: Sat, 27 Apr 2002 11:11:47 -0400

<<
So if we want to avoid confusing clients that want to interoperate
with those implementations, we probably can at most say that
"PROPPATCH SHOULD NOT modify the etag or modification date".
Sounds good.   So then an ETAG change on a resource indicates to a
client that the GET response *MIGHT* have changed.

Hopefully we can make that a very strong SHOULD so that client checking
for the "lost update problem" as part of a PUT isn't thrown off.

One thing I was concerned about is resources whose GET output changes
often in hard to predict ways.  For such live resources, the server
might chose to change the ETAG continuously rather than try to track
if the GET output has changed.  If this is a red-herring, let me know.
Upon initial blush, I'd think that this means that "lost-update-checking"
will always fail.  But I think the answer to that is, you don't do a PUT
against the live resource.   You should do your PUT/PROPPATCH requests
against source resources because they don't have this behavior.

Does everyone agree on that?

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 29 Apr 2002 09:28:35 +0200

> client that the GET response *MIGHT* have changed.

Fine with me.

> if the GET output has changed.  If this is a red-herring, let me know.

I think for continuously changing content, the server should not
generate an ETag at all. If content changes more frequently than
clock resolution (1 second), the server should send an Expires
header with a date in the past.

> against source resources because they don't have this behavior.

Such resources would most likely be read only, I agree.

//Stefan

---

From: Erik Seaberg <[email-masked]>
Date: 29 Apr 2002 10:49:03 -0700

Jason Crawford <[email-masked]> writes:

> One thing I was concerned about is resources whose GET output
> changes often in hard to predict ways[....] But I think the answer
> to that is, you don't do a PUT against the live resource.

Are servers commonly expected to keep GET on a source resource bitwise
identical with the last PUT?  It seemed transcoding, canonicalizing,
or other postprocessing at PUT time would be expected to routinely
change strong ETags (in fact we do that sort of thing to deter abuse
of a free hosting service).  Are common clients unable to accomodate
this?

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 30 Apr 2002 09:12:30 +0200

> identical with the last PUT?  It seemed transcoding, canonicalizing,

Not at all. Etags are no CRC on the content - a client cannot
calculate an ETag before the PUT.

> of a free hosting service).  Are common clients unable to accomodate

Etags are not to be touched by caching proxies. With transcoding 
proxies,
I'm not sure what they should do.

To answer your question: I don't think that any plain HTTP or WebDAV
client will be confused by rapidly changing Etags as such.

However, the other side of the coin is that it makes sense for editable
content (say a PDF document) to keep their ETag between PUTs. Clients
can then use the ETag (and are indeed encouraged to do this) to check
for unexpected changes to the document they are about to replace.

//Stefan

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 30 Apr 2002 10:43:34 -0700

> for unexpected changes to the document they are about to replace.

At risk of belaboring the obvious, I'd like to add that clients SHOULD check
the ETag when doing a PUT request (it's just one extra header).  This should
be done even if the client things they've locked the file because locks can
go away or (although wrongly) be used by another process owned by the same
user.

Thus, if clients SHOULD check the ETag before putting the file, it makes it
even more important for servers not to change the ETag unless the contents
have actually changed.  Changing the ETag when the body is unchanged could
result in a poor user experience, if their application has to pop up a
dialog or return an error saying "The file you are trying to save MAY have
been changed.  Do you want to save your changes anyway?"

lisa