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

Lisa Dusseault wrote:

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

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

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

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

Received on Monday, 27 October 2003 12:42:52 UTC