The mysteries of &cHash
By Kasper Skårhøj
The &cHash parameter of frontend plugins might have puzzled quite a few developers but this article will explain how it works and what to avoid in order to make great, reliable plugins with TYPO3.
Intended Audience
Developers of frontend plugins for TYPO3 and people who think hash is something you smoke.
Caching principles
The basic principle of caching is to spend time to generate an answer only once and then deliver that answer to the same question many times.
For websites that means using webserver resources for page generation only one time and then deliver the result over and over again when people request the page by the same parameters.
Basic page caching in TYPO3
When a page in TYPO3 is requested, an &id parameter is used to identify the page. TYPO3 will start a process which generates the page content from all the components it consists of. This process takes resources from the webserver. The next time a user asks for the same page, why not just pass the result of last time the page was generated? This is what we do when caching pages in TYPO3, thus saving server resource and speeding up the surfing experience. The generated pages are temporarily stored in a database table, cache_pages.
However TYPO3 allows the same page ID to produce different output based on more parameters than just the &id. For example the “&type” parameter is directly supported by TYPO3 for such a purpose (usually for generating sites with frames). So the caching mechanism has to store two different pages when “?id=123” and “?id=123&type=1” is called. In other words; A cached page must be identified by a combination of variables.
Snakes in paradise
An easy solution to caching would be to simply identify a page by its URL. So when someone asks for “?id=123” and “?id=123&type=1” we will just md5-hash the URL and use that to look up the page next time.
Well, that would provide the basis for a major DoS attack. What if someone requests 1 million URLs with random parameters like “?id=123&USELESS_PARAMETER=[any random number]” - that would spam our database with gigabytes of cached instances of... the SAME page!
Binding the devils...
The solution to this problem is to cache only when known and valid parameters are sent. So in reality TYPO3 will cache “?id=123&USELESS_PARAMETER=[any random number]” under the same identification as “?id=123” because the USELESS_PARAMETER is unknown to TYPO3 and the page content is the same. The reason why “?id=123” and “?id=123&type=1” will be cached as different pages is because TYPO3 is hardcoded to acknowledge the “&type” parameter as generating different page content. And even then the value of “&type” is checked – setting it to “&type=987654321” will not spam the caching table since no matching “typeNum” value is found in the TypoScript template!
... but not yourself
However developers want to use GET variables in their plugins which are not ignored by TYPO3s caching mechanism. For example a plugin found on page 566 might want to use the parameters “?id=566&tx_myext[uid]=44” to display the full news article #44 while the main page “?id=566” displays the overview. But because the GET variable “tx_myext[uid]” is completely unknown to the TYPO3 core the page will be cached only based on the page id – which is not good enough if you have more than one news article!
There can be three solutions to this problem:
&no_cache=1 (slow): Each link involving more parameters than the &id must contain “&no_cache=1” in addition, effectively disabling caching of the whole page. In this way it is safe to create custom content based on GET variables but the performance is poor since no caching is applied.URL Examples:
USER_INT (medium): Make the plugin a USER_INT type. In this way the page is cached only one time with a placeholder which is substituted by the content of the plugin being run dynamically on each request. This caches the static parts of a page but still involves the overhead of processing the plugin.
With this solutions “?id=566” will be picked up for caching by the system while “&tx_myext[uid]=44” will be used dynamically in the plugin thus taking effect on the final output.
This solution is the most flexible because you don't have to worry about caching and parameters. Recommended for realtime and user customized content such as search plugins, booking forms, user setting pages etc.
URL Examples:&cHash (fast): Each link involving more parameters than the &id must contain “&cHash=[hash string]” in addition. The value of “&cHash” is used on the server to verify that the combination of additional parameters is made by the server itself and not forged by an outside spammer.URL Examples:
