W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

RE: HTTP If-* headers

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 26 Apr 2002 12:41:46 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B15F@SUS-MA1IT01>
To: w3c-dist-auth@w3c.org
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.


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

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,

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

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:25 UTC