- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 4 May 2001 14:45:10 +0100
- To: ietf-dav-versioning@w3.org
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) RFC2616#sec14.29 "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. Regards, Tim -----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). Cheers, Geoff -----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