Using Cache-Control Headers in TYPO3

The theory of client-side caching

When we say client-side caching, this isn't strictly referring to client as in web browser, but can also refer to a proxy anywhere in the transmission chain. Anyway, without the cache-control headers, a page that is requested from a site run with TYPO3 is always transmitted in full. The caching of TYPO3 suppresses only the full rendering of the requested page by TYPO3 (saving a lot of database queries), but the content read from the cache is still sent to the client all the time. If we enable caching by sending the needed cache-control headers, any proxy or the browser itself may cache the page locally. So when a page is requested and an existing cached copy is still valid (i.e. not too old), it is not transmitted from the server to the client at all. Obviously this will reduce network usage as well as the load on the server. Cache-Control headers To provide control over the caching of web pages, the HTTP/1.1 protocol defines a set of headers that can be sent back and forth between server and client. Those allow you to prohibit caching completely (as is needed for any page that is truly dynamic, such as search results or pages depending on your login). Forcing revalidation Since in some situations a client may need to actively circumvent a cache and fetch a fresh copy from the original server, HTTP/1.1 defines ways to do so. If a client sends specific headers (usually after reloading with Shift or Control pressed), any cache involved must not use a cached copy but check for a new one first.

Enabling cache-control headers in TYPO3

There is a new option called sendCacheHeaders in the CONFIG top level object of TypoScript. If it is set, TYPO3 will output cache-control headers to the client. This conditionally allows client browsers and/or reverse proxies to take load off of TYPO3 websites. The conditions for allowing client and/or proxy caching are the following:

• The page was cached by TYPO3

• No *_INT or *_EXT objects were on the page (e.g. USER_INT)

• No frontend user is logged in

• No backend user is logged in

If these conditions are met, headers are sent that allow caching of the page. In case caching is not allowed after evaluating the above conditions, headers are sent to prohibit client caching. Details about what headers are sent can be found in TSref. To avoid potential problems TYPO3 of course honors client requests for cache revalidation and regenerates a page internally if asked to do so. More on caching and FE user logins Above it has been said that cache-control headers are not sent when a user is logged in. This is needed because in TYPO3 the same URL can show different content depending on whether a user is logged in or not. But if the same URL was visited without a login prior to the login (therefore allowing caching) the user will still see the page from cache when logged in - and so thinks he is not logged in anyway! One way to solve this, is to have different URLs when users are logged in (this could be achieved with the realurl extension). Another way is to set the sendCacheHeaders_onlyWhenLoginDeniedInBranch option in the CONFIG top level object of TypoScript. Then cache-control headers are only sent when user logins are disabled for a page or a branch of pages (possible in the "Advanced" page type). Since many sites only need the login in a certain branch of the page tree, disabling it in all other branches makes it much easier to use cache-control headers in combination with logins: cache-control headers will simply be sent when logins are not allowed and never be sent when logins are allowed! Practical Considerations Notice that enabling caching means you have to consider how log files are written: When a page is cached on the client, it will not be requested from the web server, thus no logging will happen. Often the client will ask the proxy and using Apache as proxy makes it easy to get the same logging as before. So there are ways to circumvent these problems but they are outside the domain of TYPO3 in any case.

Conclusion

Again Ole Tange: "After implementation we see a speedup factor in the order of 4-5. The reason we do not get more is that extension writers often do not think in terms of caching; so they will default their extension to be not cacheable (e.g. by making it an INT-object). We have had remarkably few problems with the caching. If editors want a change to be published immediately they simply use the web browser's facility to bypass the cache (forced reload - CTRL-F5 or Shift-Reload)." Further reading TSref, section CONFIG <link http: typo3.org documentation document-library core-documentation doc_core_tsref view>typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.6.0/view/1/6/ RFC 2616, section 14.9 <link http: www.w3.org protocols rfc2616>www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlThanks Thanks to Ole Tange for co-authoring this feature as well as providing input for this article, Robert Lemke for preparing the nice template for this document and of course Kasper for all the fish. About the author Karsten Dambekalns lives in Braunschweig / Germany with his beloved wife Līga and their (nameless) espresso machine. He actively participates in the TYPO3 community and can confirm this is a great thing to do.