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<meng...@yahoo.com>  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)?


users mailing list

Reply via email to