19 May
2010
19 May
'10
12:42 a.m.
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?
Thanks,
Felix
19 May
19 May
10:47 a.m.
Hi Felix,
On Wed, May 19, 2010 at 00:42, Meng Wu <mengxwu(a)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
Thanks,
Felix
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
12:03 p.m.
On 05/19/2010 10:47 AM, Guillaume Lerouge wrote:
Hi Felix,
On Wed, May 19, 2010 at 00:42, Meng Wu<mengxwu(a)yahoo.com> wrote:
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).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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 
12:12 p.m.
On May 19, 2010, at 12:03 PM, Sergiu Dumitriu wrote:
On 05/19/2010 10:47 AM, Guillaume Lerouge wrote:
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
Hi Felix,
On Wed, May 19, 2010 at 00:42, Meng Wu<mengxwu(a)yahoo.com> wrote:
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). 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
5331
days inactive
5332
days old
3 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Meng Wu -
Sergiu Dumitriu -
Vincent Massol