[TYPO3-ect] 4.1.0: Request parameters could not be validated

[Steffen Kamper]

"Elmar HInz" <elmar.hinz at team.MINUS.red.DOT.net> schrieb im Newsbeitrag 
news:mailman.1.1173201628.23785.typo3-team-extension-coordination at lists.netfielders.de...
>>
>> ah - very good.
>> But - the problem is not solved, only there is no errormessage. The
>> confusing about cHash still exist. Unfortunally i have not the time to 
>> make
>> a real dig into core, projects are prior atm and other problems still 
>> eats
>> time.
>>
>> vg  Steffen
>
>
> Hi Steffen,
>
> with the cHash the server signs, that the link with exactly this
> parameters origins from the server and that the resulting page is
> requested to be cached. As my yesteradays tests show, this rule is valid
> even if the parameters have no designator at all and if there is no
> receiver of the paramters.
>
> So the basical concept is really simple to understand. Build a link with
> any parameters. Subscribe them with the appropriate cHash and the
> resulting page will be cached. Point.
>
> The question is: What is the $GLOBALS['TSFE']->reqCHash(); setting for?
> (Hint: In tslib_pibase this is done indirectly by setting $pi_checkCHash
> =TRUE)
>
> It is to enable caching of more than one version of the same page. We have
> different versions if at least one USER plugin is present. That is why
> $GLOBALS['TSFE']->reqCHash(); is typically set inside a USER plugin. So
> $GLOBALS['TSFE']->reqCHash(); must be called at least one time, typicallay
> within a USER plugin.
>
> So far. But very big questionmarks occur at this point:
>
> ========================================================================
> Why is $GLOBALS['TSFE']->reqCHash(); not set by default inside the core?
> ========================================================================
>
> Why do we do all this complicated settings within plugins? This question
> has to go to Kasper. I can't give a satisfying anser to it. To me this
> and one ore two other points seem to be more complicated than necessary.
>
>
> Regards
>
> Elmar
>
>
>
Hi Elmar,

you're right, this is exactly the point where i get lost.
Understanding cHash is not difficult - this is for a given status of a page 
with a set of piVars, that will be cashed. It's needed to seperate these 
different versions of a page - very easy.
the reqCHash - in my (and your) eyes it has nothing to do with the 
extension. The extension is USER or USER_INT, which is clearly with(out) 
cache.
So core has to look for (or pi_base or whatever).
I think the confusing comes from deciding: make link with or without cache 
(link to an USER object with(ot) cache, link to a USER_INT object with(out) 
cache - does the combinations really make sense ?)

Another point, which makes it difficult for me:
A page has several objects. If there is at least one USER-Object, the Page 
has to be cached with cHash. But this could not be decision of a single 
object. And this is the point where all comes really complex. I still wonder 
how it works, because it works, but many developers using "dirty tricks" to 
prevent the cache like adding a no_cache-param.

vg  Steffen