For some time now we have had complaints from some of our customers that the icons used in our menus never seem to be cached ... various fixes have been implemented by atlassian however unfortunatley none of them seem to have been 100% effective.

In my own testing, using firebug pointed at a server running confluence 2.5.3 and builder 3.0 I got the following results:

• when you refresh (f5) a page, all of the icons are reloaded
• If you click into the address bar and use return to refresh the page, the icons come from the cache.
• If you click on the page title in the breadcrumbs to refresh the icons come from the cache.
• If you click on another page in the breadcrumbs(eg the parent), the icons come from the cache.
• If you click back to the original page, the icons come from the cache.
• If you click back the icons come from the cache.
• If you click forward the icons come from the cache.

However ... when I came back to re-test those results a second and third time I found that whether the images come from the cache or not is also reliant on the amount of time passed between the initial page load and the refresh/reload

Dan recently found a tool (http://www.ircache.net/cgi-bin/cacheability.py) which can check a page's cacheability and this is what it has to say about plugin resources :

------8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<------
http://test.wiki-neon.adaptavist.com/download/resources/com.adaptavist.confluence.themes.sitebuilder:sitebuilder/icons/printer.png
Expires -
Cache-Control private
Last-Modified 16 hr 47 min ago (Wed, 11 Jul 2007 02:46:21 GMT) validation returned same object
ETag "1184121981000"
Set-Cookie jsessionid=Ij2GFRbUVobCb1Z2or; path=/
Content-Length - (actual size: 806)
Server Resin/3.0.18

This object doesn't have any explicit freshness information set, so a cache may use Last-Modified to determine how fresh it is with an adaptive TTL (at this time, it could be, depending on the adaptive percent used, considered fresh for: 3 hr 21 min (20%), 8 hr 23 min (50%), 16 hr 47 min (100%)). It has a validator present, but when a conditional request was made with it, the same object was sent anyway. It won't be cached by proxies, because it has a Cache-Control: private header. This object requests that a Cookie be set; this makes it and other pages affected automatically stale; clients must check them upon every request. It doesn't have a Content-Length header present, so it can't be used in a HTTP/1.0 persistent connection.
------8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<------

Hopefully that should be of some use in resolving this long-standing issue ... thanks for all your effort on this so far, I think we are probably pretty close to getting it licked, its just that last 10% eh?