Content is not cached and white page displayed with big content / PHP 5.2.1
This problem originally occurred on typo3.org (ter_doc_pi1) but can be reproduced independently:
If a frontend plugin returns a large amount of content, this content is not written into the page cache. In addition not even the page without the FE plugin output is shown, but instead only a white page is displayed (which will be cached).
Use the attached extension to reproduce the behaviour:
- Install the FE plugin from the exploit extension on any page
- Make sure that you're running PHP 5.2.1
- View the page containing the FE plugin, the page should be blank
- Set the no_cache flag in the page properties or add "no_cache=1" to the GET parameters
- View the page containing the FE plugin, the page should display the content
Obviously the problem has nothing to do with the FE plugin itself (hence the exploit extension). While debugging, it turned out that in tslib_fe->setPageCacheContent() the $content is already empty: Therefore the empty content is (correctly) stored in the cache_pages table.
The content disappears somewhere between the "return" of the FE plugin in the setPageCacheContent method in tslib_fe.
(issue imported from #M5221)
#1 Updated by Robert Lemke over 12 years ago
Additional note: For some reason the caching seems only to fail with the HTML content I put into the exploit extension (which is the real content which should be rendered at typo3.org). If I replace the HTML content by some generated string (with str_repeat) of a similar size, the whole caching DOES work.
#4 Updated by Robert Lemke over 12 years ago
@Popy: Not a bad guess! I found it ...
It's not Tidy or the XHTML cleaning but it is some postprocessing. The function prefixLocalAnchorsWithScript() in tslib_fe consists of these two lines:
$scriptPath = substr(t3lib_div::getIndpEnv('TYPO3_REQUEST_URL'),strlen(t3lib_div::getIndpEnv('TYPO3_SITE_URL')));
$this->content = preg_replace('/(<(a|area).*?href=")(#[^"]*")/i','$1' . htmlspecialchars($scriptPath) . '$3',$this->content);
The problem is that - at least with the HTML rendered by ter_doc_pi1 - the regular expression returns an empty string.
For now I disabled this function with "config.prefixLocalAnchors >". Now it's up to someone else checking the regular expression and it's dependency on a certain PHP version ...
#6 Updated by Dmitry Dulepov over 12 years ago
Possible solution described here: