On May 19, 2010, at 12:03 PM, Sergiu Dumitriu wrote: > On 05/19/2010 10:47 AM, Guillaume Lerouge wrote: >> Hi Felix, >> >> On Wed, May 19, 2010 at 00:42, Meng Wu<[email protected]> wrote: >> >>> Hey all, >>> >>> We've been having browser caching problems for attachments where users have >>> had to wait hours before their data would be updated in xwiki.For IE, for >>> example, killing all instances of IE, restarting the browser, and then >>> visiting the attachment is a solution to this problem. We basically need a >>> way to add a Cache-Control header when the server responds to the attachment >>> link. Is there a way to prevent caching of the URL for attachments in the >>> web browser by changing the config files, or by changing something in the >>> xwiki code? >>> >> >> A solution I've implemented is to change the template that serves >> attachments to add the revision number at the end of the attached file >> download link (in attachmentsinline.vm >> ): >> >> <span class="name"><a >> href="$doc.getAttachmentRevisionURL(${attach.filename}, >> ${attach.getVersion()})" >> title="$msg.get('core.viewers.attachments.download')">#packName($attach.filename)</a></span> >> >> Guillaume > > This has the advantage that it still allows caching while the document > version is the same, which is good for performance, but it has the > disadvantage that it needs template changes, which is problematic for > upgrades. The best way to prevent problems is to attach the modified > template to the skin document (XWiki.DefaultSkin by default). > > Another option is to configure this in the front-end (Apache HTTPD > settings, if you use such a front-end).
hmm if this is a good thing to have why don't we have it by default in XE (it seems to me like a bug if when you add a new version of an attachment you get the old cached version)? Thanks -Vincent _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
