- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 5 Sep 2003 23:52:25 +0200
- To: "Nevermann, Dr., Peter" <Peter.Nevermann@softwareag.com>, <w3c-dist-auth@w3c.org>
> 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 17:53:15 UTC