RE: HTTP If-* headers

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:stefan.eissing@greenbytes.de]
Sent: Friday, April 26, 2002 12:19 PM
To: w3c-dist-auth@w3c.org
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

Received on Friday, 26 April 2002 12:42:18 UTC