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

I agree with Lisa's points below, especially the last point, i.e.
that we should provide guidance to clients that they should always
check for equality of the Last-Modified value to what they
previously retrieved.

Cheers,
Geoff

"Lisa Dusseault" <lisa@xythos.com> wrote on 09/09/2003 07:39:19 PM:

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