Project

General

Profile

Actions

Bug #20372

closed

Exclude &L parameter from &cHash params

Added by Michael Stucki almost 15 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-04-28
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #29365: better cHash calculation (avoid cache flooding of USER_INT)Closed2011-08-30

Actions
Actions #1

Updated by Vladimir Podkovanov almost 15 years ago

+1 for adding &L to excluded parameters
It related not only to RealUrl but also to the fact that page cache is being build again instead of using old one if you use links like
/?id=123 and /?id=123&L=0&cHache=12345
cHache in second link can appear if you use additionalParams with stdWrap processing where these params calculated. So sometimes you have additional params added, sometimes not – depends on processing in stdWrap, but cHach will be added anyway (if L param setted) though cHash is not needed if additinal params absent. And it leads to building new excessive cache instead of using old one.

Actions #2

Updated by Vladimir Podkovanov almost 15 years ago

Real example for above comment from my current pjt
typolink {
parameter.data = TSFE:id
useCacheHash = 1
addQueryString = 1
addQueryString.exclude = view_id,expand,inlist,cHash
additionalParams = &p={global:tx_myext_pi2|cur_page}
additionalParams {
if.isTrue.data = global:tx_myext_pi2|cur_page
insertData = 1
}
}
Even when all addQueryString params are filtered out by exclude list and no data in additionalParams the link still has cHash if &L was set.
Like /?id=123&L=0&cHache=12345 but should be /?id=123&L=0

Actions #3

Updated by Michael Stucki almost 15 years ago

Side note: Actually the of the useCacheHash setting is the bigger problem here, so it should be dropped from the TypoScript example. Never use useCacheHash while appending the QUERY_STRING. Instead, TYPO3 should automatically detect existing cHash values and just recalculate them.

However, the described bug can still occur if there is a plugin with cHash links on the entry page...

Actions #4

Updated by Vladimir Podkovanov almost 15 years ago

Yeah, if the page being accessed without parameters then no cHash provided and addQueryString not enough to generate one. That's why .exclude=cHash and useCacheHash = 1 are there and it is working right until &L involved.
I mean in case we have no &L, and addQueryString was filtered out via exclude list and no additionalParams left after stdWrap then typolink produces clean link without cHash as should be. But if &L was setted then cHash appears.

I think If &L parameter would be filtered out in cHashParams() as you have proposed it would be enough to resolve above case.

Actions #5

Updated by Tilo Baller almost 11 years ago

  • Target version deleted (0)

This Ticket can be closed.

&L is exluded by default from cHash calculation, see:
http://typo3.org/api/typo3cms/_default_configuration_8php_source.html#l00641

Actions #6

Updated by Michael Stucki almost 11 years ago

  • Category deleted (Communication)
  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions #7

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF