W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: getlastmodified of collections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 8 Sep 2003 15:41:45 +0200
To: "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEFAIGAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Geoffrey M Clemm
> Sent: Monday, September 08, 2003 2:11 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: getlastmodified of collections
> I agree with Lisa's observations below, and my conclusion is that since
> the behavior of GET on a collection is not defined, the behavior of
> DAV:getlastmodified should not be defined, since the purpose
> of the Last-Modified header is to support caching of the GET request.

To clarify: the behaviour of GET and the HTTP Last-Modified header *is*
defined by RFC2616. A collection may or may not have gettable
representations (as any other resource), but if it does, the Last-Modified
header must obey RFC2616's rules (that is, if it's present it must change
when the GETtable content changes). The behaviour for DAV:getlastmodified
follows automatically.

> So until 2518 defines server-independent behavior of GET on a collection
> 2518 should remain silent on DAV:getlastmodified on a collection.

Yes. In particular, if we see a use case for a last modified timestamp that
is not directly tied to content changes, we need to define a new one. This
may be optional (as all the other timestamps we have), so it shouldn't be a
problem getting it into RFC2518bis.

Maybe a topic for the interop event?


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 8 September 2003 09:50:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC