[TYPO3-core] RFC: Add feature #6547: Allow ignoring of the the no_cache parameter

[Steffen Kamper]

"Michael Stucki" <michael at typo3.org> schrieb im Newsbeitrag 
news:mailman.1.1204420417.7745.typo3-team-core at lists.netfielders.de...
> REMINDER
>
> Well I consider this a security related feature because this can in
> theory be used for DOS attacks. But of course, the primary goal is to
> help getting rid of any no_cache usage.
>
> Attached is a new patch which calls t3lib_div::sysLog() in every case
> when $TSFE->set_no_cache() is called. This will be pretty helpful to see
> how often and because of what the caching was disabled.
>
> Comments: There is no easy way to trigger this when $TSFE->no_cache is
> set directly. We could probably protect it and enforce usage of
> $TSFE->set_no_cache(), but then again this might block some existing
> (faulty) extensions...
>
> The code is pretty simple so it should be easy to approve this change.
> Thanks in advance!
>
> - michael
>
> Michael Stucki schrieb:
>> This is an SVN patch request.
>>
>> Type: New feature
>>
>> Bugtracker references:
>> http://bugs.typo3.org/view.php?id=6547
>>
>> Branches:
>> Trunk only
>>
>> Problem:
>> | The &no_cache parameter is the number one reason for unneccessarily 
>> slowing
>> | down a website.
>> | There are better ways to turn off caching for certain parts of a 
>> website,
>> | therefore the parameter should be removed.
>> |
>> | This will require lots of extensions to be changed, therefore I suggest 
>> to
>> | introduce this change in two steps:
>> | 1. Allow disabling of the parameter so that developers can see what 
>> would
>> | break
>> | 2. Finally, enable the parameter by default
>>
>> Solution:
>> Start by implementing the first step
>>
>> Notes:
>> This is my last patch before I will leave for 2 months holiday! In this 
>> time,
>> Ingmar will substitute me wherever it is needed.
>> Have fun, and see you next year... :-)
>>
>> - michael
>>
>

+1 by reading and testing.
To get rid of no_cache core has to deliver an alternative way because i 
think building USER_INTS by cObjGetSingle could be to complicate for some 
devs and an easy wrapper for that would help on this road.

vg  Steffen