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

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 26 Oct 2003 15:41:48 -0800

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 09, 2003 4:39 PM
> To: 'Chris Knight'; 'Geoffrey M Clemm'
> Cc: [email-masked]
> 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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Chris Knight
> > Sent: Tuesday, September 09, 2003 3:37 PM
> > To: Geoffrey M Clemm
> > Cc: [email-masked]
> > 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.)
> > 
> > 
> 
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2003 18:37:26 +0100

> rev of 2518bis after this deadline anyway.

It seems to be a good idea to add these kinds of notes. Looking at your 

 >> - the behavior on directories is probably completely random

...we probably should make clear what kind of behaviour indeed is ok 
according to the spec (to avoid implementers saying "but RFC2518 says 
it's ok to do this..."). For instance, changing the value of the 
Last-Modified header to an earlier value as a result of a namespace 
operation is something I'd call a RFC2616 compliance issue.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760