Bug #89353
closed
Disable cache on errors in content object
0%
Description
Errors/Exceptions should never be cached - imagine a temporary remote service outage.
Currently the result of this is cached.
page = PAGE page.10 = USER page.10.userFunc = Vendor\Extension\Test->throwException
Also it's inconsistent because the result of the default ExceptionHandler is not cached.
Updated by Gerrit Code Review over 4 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/61897
Updated by Gerrit Code Review over 4 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/61897
Updated by Gerrit Code Review over 4 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/61897
Updated by Benni Mack about 4 years ago
- Status changed from Under Review to Accepted
see from the gerrit review....
Both of the topics revolve around the information that TYPO3 should not consider any of these parts as "cacheble" or "success". But this is highly dependent on the context.
How would a developer know if a status code showed up? We're lacking lots of proper configuration to inform the developer that there is an issue.
I give you an example: Somehow a developer added a plugin "World Clock" into each page on the right sidebar. Now, the rest of the page shows up, gets cached etc. and still works fine. But the World Clock plugin is only compat with e.g. PHP 7.2.4 or lower but not with PHP 7.2.5+, and the hoster just updated the PHP version - this would make all the pages (which show proper content for the rest) as an error PLUS open up the risk for DoS due to not caching at all. However, the developer is out-of-office / on vacation but put this thing in TypoScript, so the editor cannot remove it - would you consider caching this and sending out 200-response? I would.
But of course, having a faulty EXT:news because a newly added news, should result in a 500 on the detail page because of a manually removed image. Stuff like that makes it hard to find the right path here. Both options are valid, but the current status does not open the door for DoS, which is the main benefit for me in terms of "strong default".
Updated by Benni Mack about 4 years ago
- Target version changed from next-patchlevel to Candidate for patchlevel
Updated by Benni Mack almost 4 years ago
- Status changed from Accepted to Closed
Closing this issue for the time being once we find a proper solution, we can reopen the ticket.