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 >Received on Tuesday, 9 September 2003 22:02:17 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT