Project

General

Profile

Actions

Bug #83755

closed

Extbase TYPO3\CMS\Extbase\Mvc\Controller\AbstractController->redirectToUri() – remove HTML redirect?

Added by Hagen Gebauer about 6 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
-- undefined --
Assignee:
-
Category:
Extbase
Start date:
2018-02-02
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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>

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #88178: Page cache is deleted, when an uncached (Extbase) Plugin performs a redirectClosed2019-04-19

Actions
Actions #1

Updated by Michael Stucki about 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!

Actions #2

Updated by Riccardo De Contardi over 5 years ago

  • Category set to Extbase + l10n
Actions #3

Updated by Markus Klein over 5 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

Actions #4

Updated by Markus Klein over 5 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.

Actions #5

Updated by Markus Klein over 5 years ago

The issue only occurs if the action is a cached action.

Actions #6

Updated by Gerrit Code Review over 5 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

Actions #7

Updated by Gerrit Code Review over 5 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

Actions #8

Updated by Gerrit Code Review over 5 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

Actions #9

Updated by Gerrit Code Review over 5 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

Actions #10

Updated by Markus Klein over 5 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #11

Updated by Helmut Hummel almost 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.

Actions #12

Updated by Helmut Hummel almost 5 years ago

  • Related to Bug #88178: Page cache is deleted, when an uncached (Extbase) Plugin performs a redirect added
Actions #13

Updated by Benni Mack almost 5 years ago

  • Status changed from Resolved to New
  • Target version changed from Candidate for patchlevel to next-patchlevel

Reopened the issue

Actions #14

Updated by Hagen Gebauer almost 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);
        }
    }
Actions #15

Updated by Benni Mack almost 5 years ago

  • Target version changed from next-patchlevel to Candidate for patchlevel
Actions #16

Updated by Alexander Schnitzler almost 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.

Actions

Also available in: Atom PDF