Supporting Conditional GET When Serving Plugins Downloadable Resources

One of the current problems with the plugins system is that resources served up don't have Last-Modified and ETag headers on the way out, nor do they listen to If-Modified-Since and If-None-Match headers on the way in. This means that the resources served can't be effectively cached by browsers.

Providing this capability is known as supporting HTTP Conditional GET - Charles has written about this in his blog.

Confluence supports conditional get natively for plugin resources in version 2.2. You will only need to apply this patch for Confluence 2.1.x and earlier.

Other areas of Confluence have these modification headers - so why not plugin resources?

Well it seems that the plugin system doesn't serve up the date the plugin was instantiated (the date the Plugin object was created in the running Confluence system). This means that working out a modification date is a little tricky as there is no way to know if the plugin has been updated. So first, the base class StaticPlugin in atlassian-plugins needs to be extended to add such a field. Secondly, the serving class PluginDownloadServlet in confluence will need to be extended to utilise the LastModifiedHandler class which is used elsewhere for modification header handling.

The following source modifications will result in a new atlassian-plugins jar and new PluginDownloadServlet class file you can replace in your installation. You will need:

• Access to the Confluence source code - the modifications here are against version 2.1.4 of Confluence but may work for others
• An environment setup to compile confluence - see Building Confluence From Source Code
• An editor to make the changes

The classes we are interested in are:

1. Extend StaticPlugin to have a creationDate field

Add the field code below the list of field definitions at the top - this ended up being line 21 in Confluence 2.1.4:

private Date creationDate = new Date();

Add the getter code to the end of the class - this ended up starting at line 178 in Confluence 2.1.4:

public Date getCreationDate() {
    return creationDate;
}

You may need to add the an import for java.util.Date if your IDE doesn't do as much of your work as it should.

2. Compile the changes

Execute maven jar inside of ./plugins to have maven build and produce a target/atlassian-plugins-0.3.12.jar which can be copied over the existing one in WEB-INF/lib.

3. Extend PluginResourceDownload to have use the creationDate field to base it's modified header handling on.

Find the code below that actually serves the downloadable resource up - this ended up being line 105 in Confluence 2.1.4:

serveDownloadableResource(servlet, httpServletResponse, resource);

Add some code before it so that it now reads as follows - with the serveDownloadableResource(...) ending up on line 119 in Confluence 2.1.4:

// Check the modification
Plugin plugin = pluginManager.getPlugin(resource.getPluginKey());
// Find the last modified date
Date date = null;
if (plugin instanceof StaticPlugin) {
    StaticPlugin sPlugin = (StaticPlugin) plugin;
    date = sPlugin.getCreationDate();
}
// Run the last modified logic
LastModifiedHandler lastModifiedHandler = new LastModifiedHandler(date == null ? new Date() : date);
if (lastModifiedHandler.checkRequest(httpServletRequest, httpServletResponse)) {
    return;
}
// Serve the file
serveDownloadableResource(servlet, httpServletResponse, resource);

Confluence 2.1.5a Notes The patch instructions are no longer up-to-date for 2.1.5a. You have to modify the "servePluginResource" method in "PluginResourceDownload" so that it accepts a "HttpServletRequest". Best regards, Thomas

4. Compile PluginResourceDownload

Execute maven inside of ./confluence to have maven build and produce a target/classes/com/atlassian/confluence/servlet/download/PluginResourceDownload.class which can be copied over the existing one in WEB-INF/classes/com/atlassian/confluence/servlet/download.

5. Restart Confluence

Restart Confluence and you should now see the modification headers with a HTTP "304 Not-Modified" status response if the plugin has not been updated since the last download of the plugin resource - and hopefully and marked improvement in speed!