RE: getlastmodified of collections

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

Received on Friday, 5 September 2003 18:15:56 UTC