Bug #83755
closedExtbase TYPO3\CMS\Extbase\Mvc\Controller\AbstractController->redirectToUri() – remove HTML redirect?
100%
Description
Maybe there is a point to that which I don’t see … but redirecting should in my opinion always be done with header('Location: ...') and not by the HTML meta tag. I believe that this method does that correctly at its first call – but then the HTML gets cached while response->setStatus() and response->setHeader() do not. Besides the full page HTML will be written into the content part of the template – see this simplified example:
<!DOCTYPE html>
<html>
<head>
<!-- html header from page/template -->
</head>
<body>
<div class="content">
<html><head><meta http-equiv="refresh" content="..."/></head></html>
</div>
</body>
</html>
Updated by Michael Stucki over 6 years ago
- Tracker changed from Support to Bug
- Project changed from 9 to TYPO3 Core
- Category deleted (
Development) - TYPO3 Version set to 9
Wrong project!
Updated by Riccardo De Contardi almost 6 years ago
- Category set to Extbase + l10n
Updated by Markus Klein almost 6 years ago
- Status changed from New to Accepted
- Target version set to Candidate for patchlevel
- TYPO3 Version changed from 9 to 7
Valid from v7 through v9
Updated by Markus Klein almost 6 years ago
My take on this issue:
The first plugin on a page with a redirect wins. The request can be terminated immediately to save useless processing of other plugins.
Edge-cases discussed in various places, like having plugins that need to be called for persisting data, is IMO an invalid use case and bad software design. You don't want a single request to handle multiple application logic steps at once, where one thing relies upon the other.
Updated by Markus Klein almost 6 years ago
The issue only occurs if the action is a cached action.
Updated by Gerrit Code Review almost 6 years ago
- Status changed from Accepted to Under Review
Patch set 2 for branch TYPO3_7-6 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58580
Updated by Gerrit Code Review almost 6 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58581
Updated by Gerrit Code Review almost 6 years ago
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/58582
Updated by Gerrit Code Review almost 6 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/58582
Updated by Markus Klein almost 6 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 3139b5608c87e7a5c2a49aa48cc683654db71e39.
Updated by Helmut Hummel over 5 years ago
- Category changed from Extbase + l10n to Extbase
but then the HTML gets cached while response->setStatus() and response->setHeader() do not
What is a use case for caching a plugin action that does a redirect?
Is it for enabling a plugin to perform a permanent redirect for a given URL?
I would be interested in a more concrete use case for something like that.
In any case, the implemented solution seems pretty hacky and results in the complete page never being cached (even worse, cached, but cache deleted in the end),
which is quite a performance hit for such case.
Even worse: even if the plugin action is uncached, the page cache will be deleted anyway, which leads to a unnecessary performance hit.
Updated by Helmut Hummel over 5 years ago
- Related to Bug #88178: Page cache is deleted, when an uncached (Extbase) Plugin performs a redirect added
Updated by Benni Mack over 5 years ago
- Status changed from Resolved to New
- Target version changed from Candidate for patchlevel to next-patchlevel
Reopened the issue
Updated by Hagen Gebauer over 5 years ago
Helmut Hummel wrote:
but then the HTML gets cached while response->setStatus() and response->setHeader() do not
What is a use case for caching a plugin action that does a redirect?
I have an extension with a showAction() that returns a detail view of a database record. I was trying to show a specific “this record could not be found” page with a 404 – instead of the regular 404 page of the website. This is important mostly for records that have been recently deleted but might still be linked somewhere or returned by search engines. I tried to achieve this by forwarding to a specific showNotFoundAction() (see below). Which means the forwarding is being called by an action that has to be cached (the showAction).
I am happy to hear about different solutions for that particular problem. Nevertheless, redirectToUri() is a provided method and the resulting forwarding should in my opinion never be done via an HTML meta tag. And even if it is, there is still the bug of printing the full HTML page into the content part of the template (see snippet in the original post).
public function showAction(\My\Extension\Domain\Model\MyModel $record = null)
{
if (!is_null($record)) {
$this->view->assign('data', $record);
} else {
$uri = $this->uriBuilder
->setTargetPageUid($GLOBALS['TSFE']->id)
->setArguments(['tx_myextension_plugin'=>['action'=>'showNotFound']])
->buildFrontendUri();
$this->redirectToUri($uri, 0, 404);
}
}
Updated by Benni Mack over 5 years ago
- Target version changed from next-patchlevel to Candidate for patchlevel
Updated by Alexander Schnitzler over 4 years ago
- Status changed from New to Rejected
- Priority changed from Should have to -- undefined --
Hi Hagen,
I just worked on a similar ticket and pretty much the same applies here.
- If you have an action that performs a redirect it must not be cachable. It will be retriggered as non-cacheble anyway if you mark it cachable which might result in nasty side effects.
- We are aware that the redirect logic of Extbase isn't great. The reason for the HTML redirect is because each plugin is rendered as a content object which returns (mostly html) content. Up until version 10 we don't have a proper request/response handling in Extbase to a degree that usual response properties are evaluted in the parent scope. Each dispatched plugin either returns content (a string) or throws an Exception. The Response never reaches the code beyond the dispatcher. In version 10 a lot has changed to make Extbase PSR-7 compatible and introduce a proper request/response handling but we are not there yet. This topic has a very high priority and will be worked on soon when development of version 11 starts.
Given the explanation this ticket will be rejected.
Feel free to add a comment though.