Many web applications depend require cache control for pages, especially if they involve user logons or time-dependant data.
Usually this is achieved with HTTP headers - something like (in JSP):
“
response.setHeader("Cache-Control", "no-cache"); response.setHeader("Expires","Tue, 30 May 1980 14:00:41 GMT");
An alternative, which usually work well is to require your site to be run under HTTPS. In theroy, this seems ideal, since it provides security as well as cache control.
However, beware of the impact of things like reverse-proxies. Many companies are installing reverse proxies in front of their web hosting machines to do request filtering in order to provide some protection against SQL injection & XSS attacks on their websites. This is a really good idea, but there can be some unexpected impacts.
One I didn’t expect was the impact on caching. Because the proxy needs to inspect the request, it decrypts it, then forwards the request as a HTTP request to the server. Many vendors list this as a feature, because it offloads some processing requirements tot he proxy-box, instead of the webserver. The catch comes if you don’t have explict cache control in your pages AND the reverse proxy is a caching reverse proxy. In this case the proxy may return the cached content to the user, which is NOT WHAT YOU WANT!
Another complicating factor is that some reverse proxies forward the original HTTP 1.1 requests to the server as HTTP 1.0, and seem to ignore HTTP 1.1 headers that are returned. This can bite you if you only use the “Cache-Control” (HTTP 1.1 only) header.
Lesson: Always provide explict cache control AND expiry headers, and never rely on HTTPS to control caching for you.