TYPO3 Core

Hmm, that is not easy to explain. I'll add an extended version of the problem description below, here is just what needs to be done:

Add the "L" parameter to the list of parameters to be excluded from &cHash generation in t3lib_div::cHashParams(). This helps to avoid problems with faulty cHash values that cause pages to be rendered non-cached.

Reason: The "L" parameter is de-facto standard in TYPO3-land and is always controlled by TypoScript conditions. Therefore there is no need to include it in the cHash parameter.

Here's a more detailed story:

When the &cHash parameter is computed, the typolink function first needs to know which parameters make the page unique. This is done by sending the full query string to t3lib_div::cHashParams().

The output of that function is an array with all parameters which are not respected by TYPO3 automatically, like "id", "type", "MP", and "cHash". This list is hardcoded, have a look at the function code for details.

However, there is a problem with this behaviour in combination with RealUrl:
Assume you use RealUrl with language codes within preVars, you could have the following URLs in your content:
- index.php?id=1 => /en/index.html
- index.php?id=1&L=0 => /en/index.html

As you see, both URLs map to the same path.

Now assume you're creating a print-page link using the following TypoScript snippet:
lib.printLink = TEXT
lib.printLink {
parameter.data = TSFE : id
parameter.wrap = |,98
additionalParams.dataWrap = &{getIndpEnv : QUERY_STRING}
useCacheHash = 1
}

This example will work pretty well. As you see, the cHash parameter is explicitely requested to make sure it will be rebuilt for the new URL. Again, everything works fine so far.

However, this causes the example URLs from above to be built with a cHash parameter, although not neccessary.

The example sounds very special but since a print link appears on almost every page, it will always affect the entry page of a website (see first example link):

1. index.php?id=1&type=98&cHash=1234 => /en/print.html
2. index.php?id=1&L=0&type=98&cHash=5678 => /en/print.html

Result: On the entry page, RealUrl will append the cHash parameter automatically without TYPO3 beeing aware of it. This leads to the print link containing different cHash values depending on the existence of the &L parameter. The result is that the cHash parameter validates as wrong, and the page is rendered using the no_cache option.
(issue imported from #M11004)