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: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 9 Sep 2003 22:02:11 -0400
To: w3c-dist-auth@w3c.org
Message-ID: <OF20BE7008.938E407D-ON85256D9D.0009C2F3-85256D9D.000B2FF5@us.ibm.com>
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.


"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
Received on Tuesday, 9 September 2003 22:02:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC