- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 4 May 2001 09:27:43 -0400
- To: ietf-dav-versioning@w3.org
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:28:42 UTC