Subject: Question about DAV:getlastmodified property

From: <[email-masked]>
Date: Thu, 17 Feb 2005 16:57:02 +0100

Hello everyone,

I have a question about the value of the DAV:getlastmodified property.

If I have a WebDAV server which uses an underlying file system, then the
values of that property are pretty much given by that system. If however
I have a WebDAV server which implements the resources itself, is there
some recommendation what the DAV:getlastmodified should reflect?

Changes to the contents of a resource obviously will affect the
modification date, but which properties do also do that? A rename on
Linux for example will not change the modification date. Should a
PROPPATCH on DAV:displayname also not change the modification date of a
resource? What about acquiring a LOCK or setting ACLs on a resource? Has
anybody created a list of properties which should lead to an update of
the modification date, if they are changed? Should changes to dead
properties always lead to a change in the modification date?

regards,
   Heiko Weber

===
Software AG
Tamino Development

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Feb 2005 17:09:33 +0100

> Hello everyone,

Hallo!

> Linux for example will not change the modification date. Should a

Because that doesn't really change the state of the file, but the one of 
it's parent collection (which will have an updated date)...

> properties always lead to a change in the modification date?

In general, the only thing clients can rely on is that *if* 
getlastmodified is present, it will change anytime the GETtable content 
changes (within timer resolution...). So on the other hand, servers have 
a lot of implementation freedom, as long as they don't break that contract.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 17 Feb 2005 10:00:08 -0800

> getlastmodified is present, it will change anytime the GETtable 
> content changes (within timer resolution...). So on the other hand, 
> servers have a lot of implementation freedom, as long as they don't 
> break that contract.
>
Julian's right, and there's another couple things to point out: while 
servers have a lot of implementation freedom, there are couple things 
to consider particularly when interoperating with HTTP clients unaware 
of properties.

1. Consider whether your getlastmodified will be changed everytime the 
ETag changes -- or perhaps you're not supporting ETags.  If they change 
together or ETags aren't supported, then there are cache update and 
lost update considerations (2 and 3).  If the getlastmodified and the 
ETag change at different times, then that might not cause problems but 
they do need to be considered separately.

2.  HTTP clients refresh their caches of resource bodies using the 
getlastmodified date (or the ETag if that's available and they feel 
like it).  If the getlastmodified date changes whenever properties 
change (or ACL or lock state), then HTTP clients will have to download 
the resource body unnecessarily.  That might not be a problem if 
properties change rarely or if resource bodies are small, but it is 
certainly the minimalist approach to change the getlastmodified or ETag 
only when the body changes.

3.  WebDAV clients (and possibly even HTTP clients) use the 
getlastmodified date (or the ETag) to determine whether they can take 
local changes and apply them to the resource, or whether the local 
changes will conflict with changes made by another user since the 
resource was downloaded.  If the getlastmodified date changes because 
of property value changes, then the client might have to throw away 
resource body changes unnecessarily.   I'd say that the ETag SHOULD NOT 
change when the lock state changes because WebDAV clients use that to 
see if they have to throw away changes. And that means that if the ETag 
and getlastmodified behave the same way then getlastmodified shouldn't 
change either.  (Consider the case where a client LOCKs and UNLOCKs the 
resource without changing anything.)

Note that the problem of telling when properties change is completely 
unsolved.  Clients can't rely on getlastmodified or ETag because some 
servers don't change those when properties change.   It's pretty well 
unfeasible to support offline use and synchronization of a decent 
number of actively changing properties without some extension.

Lisa