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.

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

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 09/05/2003 06:16:56 PM:

> 
> This is a good point.  I was thinking that the GET response to a 
directory
> was likely only a 
> listing of its member files, and then Geoff's idea of getlastmodified 
would
> fit this model.
> However there are a number of other possibilities:
> 
>  - If the server includes information about a directory's members, that
> could change.  E.g.
>    File Name      Size      Last Modified
>    file1.txt      123k      8/1/2003
>    file2.txt      124k      8/2/2003
>    A server that did a listing like this in response to a GET ought to
> change its directory's
>    getlastmodified value whenever the content changed. Obviously that 
might
> include a PUT
>    operation to a child as well as the other operations listed.
> 
>  - If the server returns a file like "index.html" in response to a GET 
for a
> directory, then
>    possibly the 'getlastmodified' property value for the directory 
should be
> that of 
>    the index.html file.
> 
> How many HTTP/WebDAV clients are there out there that do caching/synch 
based
> on the 
> Last-Modified header or the 'getlastmodified' property?  I am guessing 
there
> are quite
> a few because from what I've seen clients can't rely on ETag support in
> Web/WebDAV servers.
> 
> Lisa
> 
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org 
> > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> > Sent: Friday, September 05, 2003 2:52 PM
> > To: Nevermann, Dr., Peter; w3c-dist-auth@w3c.org
> > Subject: RE: getlastmodified of collections
> > 
> > 
> > 
> > > From: w3c-dist-auth-request@w3.org 
> > > [mailto:w3c-dist-auth-request@w3.org]On
> > > Behalf Of Nevermann, Dr., Peter
> > > Sent: Friday, September 05, 2003 6:19 PM
> > > To: 'w3c-dist-auth@w3c.org'
> > > Subject: DAV:getlastmodified of collections
> > >
> > >
> > > AFAIK, according to RFC2518, Section 13.7, the DAV:getlastmodified 
> > > property is not required to be defined for collections, but 
> > a server 
> > > MAY define it. Is that correct?
> > 
> > Actually, it's not really required at all. A server should 
> > provide a DAV:getlastmodified property for any resource for 
> > which it actually would also provide the last-modified header 
> > upon GET. So a collection may have GETtable content (in which 
> > case DAV:getlastmodified should be present), and then also a 
> > server may not even have the last-modified date for a plain 
> > resource (for instance if it's clockless).
> > 
> > > Then, probably the bindings of the collection are to be considered 
> > > part of the collection's state and it would make sense to set 
> > > DAV:getlastmodified whenever the bindings change:
> > 
> > I agree although I have to point out that properties *also* 
> > are part of the state of a collection, and the current 
> > consensus seems to be that the last-modified date should not 
> > change when the content doesn't. So this is non-obvious.
> > 
> > > - BIND, UNBIND (the coll identified by the req-URI)
> > > - REBIND (the coll identified by the req-URI AND the 2nd involved 
> > > coll)
> > > - PUT returning 201 (the containing collection)
> > > - MKCOL (the containing collection)
> > > - DELETE (the containing collection)
> > > - LOCK creating a lock-null resource (the containing collection)
> > > - VERSION-CONTROL on existing version (the containing workspace)
> > 
> > Yes.
> > 
> > > Sorry for such a basic question, but I didn't find it in the specs.
> > 
> > No, it's good to ask these kinds of questions.
> > 
> > Julian
> > 
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > 
> > 
> 
>