W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: File creation date, version creation date, and getlastmodified

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 4 May 2001 14:45:10 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A42.004B8CA1.00@d06mta07.portsmouth.uk.ibm.com>

at the risk of drifting too far off topic ...

Geoff wrote:
> The semantics of Last-Modified ... is phrased in
> terms of whether or not the content (as returned
> by GET) has been "modified"

You'll have to send me the reference to this, because as I read the spec.
the definition of modified is left entirely at the server's discretion
(other than the fact that the date cannot be in the future)

"The Last-Modified entity-header field indicates the date and time at which
the origin server believes the variant was last modified. [...] The exact
meaning of this header field depends on the implementation of the origin
server and the nature of the original resource."

However, we agree on the conclusions.


-----Original Message-----
"Clemm, Geoff" <gclemm@rational.com> wrote:

The semantics of Last-Modified is not phrased in terms of
what operation is being applied to a resource (i.e. it doesn't
say "a PUT always causes Last-Modified to be updated"),
but rather is phrased in terms of whether or not the content
(as returned by GET) has been "modified".  So although a server is
allowed to update the Last-Modified date (to the current date)
whenever it wants, an interoperable client cannot count on it
changing unless the content has changed (which would not be
the case for an idempotent PUT).


-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

"Clemm, Geoff" <gclemm@rational.com> wrote:
> ....  The DAV:getlastmodified changes
> if the content that would be retrieved by GET changes.

Well, if a client were to PUT the same bytes twice, the content returned by
GET did not change, but I would expect the Last-Modified timestamp to
change.  I guess that is a HTTP/1.1 discussion, and RFC2616#sec14.29 seems
quite flexible on the issue.
Received on Friday, 4 May 2001 09:46:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC