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

RE: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections)

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 9 Sep 2003 16:39:19 -0700
To: "'Chris Knight'" <Christopher.D.Knight@nasa.gov>, "'Geoffrey M Clemm'" <geoffrey.clemm@us.ibm.com>
Cc: <w3c-dist-auth@w3c.org>
Message-ID: <006a01c3772b$96db9d60$f8cb90c6@lisalap>

This sounds like the right general idea.

I'm starting to think that RFC2518 needs a new section, a non-normative
note or warning on the dangers of relying on the value of 
'getlastmodified'.  As far as I can tell:
 - some servers allow this to be modified by clients
 - on a MOVE, some servers set the destination getlastmodified to
   the source's previous value, others set it to the timestamp of the
   operation itself
 - on a COPY, same thing, but probably not on all the same servers
   that do the MOVE that way
 - some servers allow underlying file system operations to replace
   files with new files with *older* getlastmodified values
 - some servers modify getlastmodifed when props change
 - the behavior on directories is probably completely random

Thus, clients can't rely on the value of getlastmodified (or
the Last-Modified header) at all and should use ETags instead.
If the server doesn't support ETags the client is screwed.  
In that case, possibly the only reasonable thing is to throw
away your cached version anytime the last modified value changes
an iota, even if it changes to be *earlier* than your cached 
version.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Chris Knight
> Sent: Tuesday, September 09, 2003 3:37 PM
> To: Geoffrey M Clemm
> Cc: w3c-dist-auth@w3c.org
> Subject: Re: DAV:bindings-last-modified (was RE: 
> DAV:getlastmodified of collections)
> 
> 
> 
> Geoffrey M Clemm wrote:
> 
> >I believe that we have concluded that DAV:getlastmodified depends on 
> >what the server returns on a GET on a collection, and 
> therefore is not 
> >something we can define (since what the server returns on a GET on a 
> >collection is not defined).
> >
> Actually, since many servers do implement GET on a 
> collection, how about 
> saying "DAV:getlastmodified should be defined for collections if the 
> server supports GET on collections and the value of the 
> property would 
> be the last time some operation changed what would be the result of a 
> GET operation (and would be the value that would be compared 
> against if 
> a Last-Modified header was sent on said GET request)"?
> 
> Sorry, my brain is not thinking in protocol-spec-speak right 
> now, but I 
> think you get the idea.
> 
> Your other property for bindings would be useful as well, and I would 
> guess that many implementations would make them equivalent 
> (as a GET on 
> a collection would return an HTML rendering of the bindings from that 
> collection.)
> 
> 
Received on Tuesday, 9 September 2003 19:48:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT