If your browsing habits are anything like mine you may have realised, when using Confluence 2.7, that the back and forward controls on your browser seem to be much faster when traversing wiki pages.
If your browsing habits are anything like mine you may have realised, when using Confluence 2.7 (release candidate currently deployed on confluence.atlassian.com), that the back and forward controls on your browser seem to be much faster when traversing wiki pages. You may have also noticed that the annoying The page you are trying to view contains POSTDATA that has expired from cache. Yada yada… popup that you may have to contend with when clicking back to Confluence search results is also pleasantly absent.
What could bring about such a magnitude of performance improvement?
you ask. Four new CPUs on the confluence.atlassian.com server?
Nay. Hundreds of hours of performance R&D and poring over yourkit dumps?
I wish I had the time. Some strange and ancient ritual performed on the precise second of the Spring equinox which by necessity violates some eight tenths of modern law?
Not even.
That last guess may actually be closer to the mark than you would think as it did involve an exorcism – of the HTTP Cache-Control: no-store directive. How did the banishment of this lesser demon affect your experience so? It’s quite simple: no-store really does mean “do not store this response for any longer than necessary to display it”. When you navigate away from a page served as no-store your browser will expunge all traces of it (at least Mozilla based browsers do). This means when you attempt to return to the page via the browser navigation buttons, the browser must repeat the original request to the server to get the page again. This has a few ramifications apart from the extra latency for the end user when using session history controls:
- Extra load on the server.
Every time someone uses the back and forward buttons to pages on a Confluence server we have to process the request all over again. A kitten probably dies as well. - It breaks browser session history. When I click on the back button I expect to see the previous page as it was when I navigated away from it. I often do this because there was text or a link on the previous page that I was interested in using before I left the page. If the page is re-fetched from the server when I click back, on a dynamic site such as a Confluence wiki, it is likely that the content will have changed. That link I was interested in on the recently updated section of the dashboard could well have been pushed off the front page. This violates the rule of least surprise for me and degrades the utility of my browser’s session history functions. Another frustrating side effect of this is that all form state is also reset. I’ve already had a few Atlassians thank me for this improvement after they’ve accidently navigated away from a form that they were filling in, to find that their text entries were preserved when they click back. With
no-storethis state would have been lost. - For pages requested via HTTP POST such as form submissions, the browser must check with the user before repeating the request. This occurs because POST requests may be non-idempotent, meaning they may perform some action that changes state on the server. To prevent undesired side effects, such as repeating an action which deletes data, user agents ask users whether they really want the action performed again. This is of course the source of the much maligned re-post confirmation dialogue. While the Confluence search form should arguably use a HTTP GET to perform its action, the removal of
no-storekills the appearance of the pop up while we work at the slightly more trickier problem of changing it to use GET.
It looks like older versions of Confluence and present versions of Jira (the Jira developers are looking to address this) serve pages with this directive as part of a carpet bombing approach to ensure that a page is not cached by browsers, preventing users from ever seeing stale views of data on the server. no-store is inappropriate for this; no-cache is all that is necessary. I would urge developers to review their use of this directive and remove it if appropriate.
Since the caching features of HTTP 1.0 and 1.1 are often not or only vaguely understood, I recommend that all developers working on web based applications have a solid understanding of the important concepts detailed in section 13 of RFC 2616 which deals with the caching features of HTTP. More attention to details like the ones described above can lead to a much enhanced user experience with a better behaving and performing web application.