TYPO3 Core

TYPO3 Caching and the cHash

What is the goal:
1) Content that can be cached should be cached
2) Content that is dynamic should not be cached, but the rest of the page
3) Not more cache entries then required

Problem description short:
---------------------------
Currently TYPO3 takes all parameters to calculate the cHash and have a seperate cache entry for that parameter combination. But for parameters that are evaluated in USER_INT (like uncacheable actions in extbase for example) this don't makes sense and results in two problems a) uncached page because of wrong cHash or b) too much unneccessary page cache variants.

Problem in Detail: (you may want to skip reading this part and check solution below)
---------------------------

Introduction with two Use-Cases:

Use-Case 1:
- You have a single view that displays some data based on a "tx_news_pi1[uid]" parameter.
=> If you have a valid cHash for that parameter TYPO3 caches a separate variant of this page (e.g. id=12&tx_plugin_pi1[uid]&cHash=correct2343243 )

Use-Case 2: using _INT Typoscript Objects for Use-Case:
- You have a search that searches for things based on a query:
=> You are not allowed to have a cHash Parameter then. Your URLs need to look like this:
id=12& tx_search_pi1[query]=test
id=12& tx_search_pi1[query]=test2

=> TYPO3 will then have only one Cache entry for that page. But your plugin will be a USER_INT and therefore can evaluate this parameter each time.

The Problem:
----------------

1) It is not possible to have this behaviour mixed on one page: If you have elements on your page that should be cached based on some parameters but you still want to have elements that needs to be uncached. And there are many use-cases for this!

So to come back to the two examples:
id=12&tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1&cHash= correct2343243
will not work since the cHash is not valid anymore

id=12& tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1
Will not work since with a missing cHash TYPO3 might deliver the wrong cached content for the news extension

id=12& tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1&cHash=thenewcorrectchash213213
Will work but pollute the Cachetable with new entries for every tx_search_pi1 parameter.
(And the additional problem that the cHash may not be possible to calculate)

2) The current extbase uncached actions solution is another example for the same problem. Since extbase replaces USER to USER_INT on the fly if an uncached action is called it needs to have the cHash Parameter set. Which results in a new Cache entry for every Parametercombination of the uncached action. Which makes it pretty useless in most cases.

3) A third aspect of that example is, that parameters like "L" or other Parameters that might be part of some conditions are used for cHash calculation also. That can cause tricky bugs and uncached pages also.

Solution:
-------------

The cHash should (and have to) be only calculated and evaluated for parameters that are used in cachable plugins (or actions).

For the above example that means:
id=12&tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1&cHash= correct2343243
id=12&tx_search_pi1[query]=test2&tx_plugin_pi1[uid]=1&cHash= correct2343243

should both result in a cache hit.

id=12&tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1&cHash=wrongcHash
=> should trigger an cHash error  since its a wrong cHash

id=12&tx_search_pi1[query]=test&tx_plugin_pi1[uid]=1
=> should throw an cHash error too, since the cHash is missing but required for tx_plugin_pi1[uid]

The patch set introduced a new class for the cHash calculation because of:
1) it could be xclassed if there are very special requirements to cHash calculation
2) the class could be unit-testes
3) it makes sense to move features from t3lib_div for maintenance reasons