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

Was there any consensus on adding this (a section warning how 
clients can't rely on last modified)?  I didn't see any objection
but I'd like to see a more positive response or else leave it out.

In private mail, Chris also pointed out that the description of 
Last-Modified in RFC2616 is filled with SHOULD requirements instead 
of MUST, so clients can't rely on that value anyway (particularly 
when doing synchronization).

Obviously if there is consensus I won't get this new paragraph 
added before this draft deadline but there will likely be another
rev of 2518bis after this deadline anyway.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 09, 2003 4:39 PM
> To: 'Chris Knight'; 'Geoffrey M Clemm'
> Cc: w3c-dist-auth@w3c.org
> Subject: RE: DAV:bindings-last-modified (was RE: 
> DAV:getlastmodified of collections)
> 
> 
> 
> 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 Sunday, 26 October 2003 18:41:51 UTC