jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conoly, Brett" <Brett.Con...@digitalinsight.com>
Subject RE: webdav caching
Date Tue, 01 Apr 2008 15:32:27 GMT
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.

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Tuesday, April 01, 2008 11:04 AM
To: users@jackrabbit.apache.org
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
> the headers were returning the original time stamp along with the same
> Etag.  The Etag issue was caused by our Jboss server because the
> 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
> ...

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

View raw message