Firefox 3.6 now respects 'Cache-Control: private, max-age=1000' when an 'Expires' header is also present, so it will correctly cache attachments and user profile pictures.

The Mozilla guys have resolved the caching bug which preventing this caching working properly in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=203271.

Based on the Gecko product list, I think the fact that this bug was fixed in Mozilla/Gecko 1.9.2 means that it won't be in Firefox 3.5 – which is based on Gecko 1.9.1 – but in the release of Firefox following 3.5.

This is implemented for images with a version number in the URL.

Note that current versions of Firefox (up to 3.0.x) have a bug that prevents private caching working properly: https://bugzilla.mozilla.org/show_bug.cgi?id=203271. Because private caching is essential for attachments, this means that the caching improvement is not effective at reducing requests in Firefox. There's a patch on that bug which has had some recent activity and looks like it might make it into Firefox 3.1.

According to that bug (I haven't tested it personally), the caching should work properly in Safari, IE6 and Opera.

I'm working on a patch to give embedded images a version number, but it is breaking some tests related to HTML export.

Changing issue description; Agnes created a separate issue for static images.

I have created a separate issue for static images: CONF-14214

It is currently being implemented for 3.0.

Also, perhaps, add a configuration option to serve these from a different host.

Thanks Don. We quite understand the time frame issue

Hi Matthew,

We are certainly intending to move as many static images to /s/ as possible. It's not top of our list though, so I can't give you a time frame.

Cheers,
Don

Uncached files under /images are contributing to big performance problems for us.

I see in 2.8.2 that some /images are accessed via /s/ so are cached but others are hard coded in .vm files and don't use /s/.

Is Atlassians intention to move all /images to /s/ or something similar?

In the short term it's easy for me to tweak urlrewrite.xml so cache headers are added to everything under /images but that will create a huge renaming nightmare if we ever decide to retheme and change a lot of the images. However if we know that Confluence will move all images to /s/ within a few years then it would be fine.

From talking to the Confluence developers, the serving of attachments seems like a fairly simple task. As attachments are versioned, if we changed the URL from "filename?version=1" to "/1/filename" that would solve the problems.

One problem does exist when a file is attached and then deleted. Under this circumstances, you could eventually end up with two version '1's that have existed at different points in time.

One way to solve that is in Confluence - to not re-hand out the version numbers when you delete a file.

Another way would be to have another seed in the url. Currently it is :

/<attachmentid>/<filename>?version=<versionNum>

We could change it to:
/<attachmentid>/<seed>/<versionNum>/<filename>

Where seed could be an MD5 has, or the date of the attachment upload, or some other unique information.