It appears that files pulled from a resource don't cache properly in the browser so they get loaded over and over and over...

Here's an example:

Response Headers - http://www.randombits.org/download/resources/com.adaptavist.confluence.themes.sitebuilder:sitebuilder/icons/document_plain.png

Date: Wed, 01 Feb 2006 05:52:20 GMT
Server: Resin/3.0.14
Content-Type: image/png
Transfer-Encoding: chunked

200 OK

As you can see, the HTTP header is sparse to say the least.

Here's an example of an image pulled from a normal web server:

Response Headers - http://adaptavist.com/glyphs/about.png

Date: Wed, 01 Feb 2006 06:09:46 GMT
Server: Apache/1.3.29 (Unix) mod_become/1.3 DAV/1.0.3 mod_perl/1.29 PHP/4.3.9 mod_fastcgi/2.4.2
Last-Modified: Thu, 11 Aug 2005 16:28:48 GMT
Etag: "50b29b-30e-42fb7cc0"
Accept-Ranges: bytes
Content-Length: 782
Content-Type: image/png

200 OK

As you can see, there are certain things in the header that would certainly help with caching:

• Last-Modified - allow browser to know if it has the correct version of the file
• Content-Length - allow browser to know if the file is the same size
• Etag - allows the browser to check it's got the same entity reference

Then there is the chunked transfer encoding output from the resource URL - I'm just guessing here, but that's going to make it very difficult indeed for the browser to work out if it has the latest file or not? Pretend to be a web browser for a minute, and decide if you'd want to work out if you already had a chunked file cached or not:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

I don't know which of these things, if any, would actually alter caching, but it seems that if the HTTP headers from resources could be "fleshed out" a little to give some extra information, there would be a higher chance of the browser caching resources.

So, my question is: Can we output additional HTTP headers AND can we have them sent non-chunked?

Without these two vital things, pulling files from resources is going to be slooooowwww. As a growing number of plugins are using resources in this way (images, css, javascript, etc), we're going to see Confluence sites using lots of plugins getting slower and slower.

If the servlet that sends out the files uses the jar's date as the Last-Modified and also sends the file normally and puts it's Content-Length on, things should run a lot quicker for all resources pulled from plugins, ie. a Confluence-level optimisation. Of course, there may be times when a resource needs a different date (eg. dynamically created resources) so there would have to be a way to define this. From my understanding, however, resources that are simply pulled form the jar (ie. a file in the jar) will never be dynamic?

David Peterson will no doubt be along shortly to add to this (eg. the idea about dumping the files on to disk so they can be pulled more easily without needing to go in to the jar each time)...