Yeah, when we initially put our content in we updated the time stamp and that could be why it doesn't automatically update after subsequent updates but I'm not completely sure, it could be that the server never automatically updates the time stamp. Does anyone know where that may be documented; I can't seem to find it. Thanks, Brett
-----Original Message----- From: Julian Reschke [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 11:04 AM To: [email protected] Subject: Re: webdav caching Conoly, Brett wrote: >> i don't think so. > You're wrong! > Sorry don't mean to be rude but it seemed like you were being rude to > me. > > In an attempt to give you all the details of our problem we noticed that > the headers were returning the original time stamp along with the same > Etag. The Etag issue was caused by our Jboss server because the webdav > servlet was reading the timestamp off of the node and sending it back > with the old timestamp. This was my fault because I thought the time > stamp would be updated automatically on an update...stupid me. Once I > manually added the timestamp on a save the webdav servlet returned the > correct header which told the browser to return the newly updated page. > ... Are you talking about jcr:lastModified? JSR-170 doesn't require this property to be protected, but I always assumed that servers will actually set it when the content is updated. Smells like a future interop problem... BR, Julian
