Bug #94533: Extbase controller response status not working - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #94533

closed

Extbase controller response status not working

Added by Jarvis H over 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2021-07-10

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

PHP Version:

7.4

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Extbase controller actions can now return a ResponseInterface.

According to the migration notes here: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/11.0/Deprecation-92784-ExtbaseControllerActionsMustReturnResponseInterface.html#migration it should be possible to change the response code using withStatus:

public function listAction(): ResponseInterface
{
    $items = $this->itemRepository->findAll();
    $this->view->assign('items', $items);

    $response = $this->responseFactory
        ->createResponse()
        ->withHeader('Cache-Control', 'must-revalidate')
        ->withHeader('Content-Type', 'text/html; charset=utf-8')
        ->withStatus(200, 'Super ok!');
    $response->getBody()->write($this->view->render());
    return $response;
}

However, the response code always stays at '200' regardless of entering fx. '400'.

Additional info:
Typo3 Version: 11.2 & 11.3
I am using the jsonView in my extbase controller:

 protected $defaultViewObjectName = JsonView::class;

Output is rendered like so:

lib.myPlugin = USER
lib.myPlugin {
    userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
    pluginName = MyPlugin
    vendorName = ABC
    extensionName = SomeExtension
    controller = SomeController
}

JSONPAGE = PAGE
JSONPAGE {
  typeNum = 123
  config {
    disableAllHeaderCode = 1
    debug = 0
  }

  10 < lib.myPlugin
}

Actions

Copy link

Updated by Jarvis H over 3 years ago

Description updated (diff)

Actions

Copy link

Updated by Jarvis H over 3 years ago

Description updated (diff)

Actions

Copy link

Updated by Christian Kuhn over 3 years ago

Yeah.

This depends on context and isn't an issue of extbase itself: When an extbase plugin is called in FE through ContentObjectRenderer (as you do with you TS snipped above), extbase returns the request exactly as you specified, but ContentObjectRenderer then ignores it again and returns just the content string.

Your example would work if you're using extbase within a BE instance, for instance.

So the main issue are ContentObjectRender and TyposcriptFrontentController here and the issue could be fixed there. If this is a huge issue, I'd suggest to have some intermediate solution within Extbase/Core/Bootstrap handleFrontendRequest(), this already handles responses with status codes >=300, Content-Type's, and similar.

Actions

Copy link

Updated by Jarvis H over 3 years ago

Thanks for the quick reply.

Just to clarify: I am making a simple API, where it would be optimal to be able to control the response codes.

I presume the long-term plan is to replace all legacy http handling with PSR-7, and that this is still WIP?

I found an alternate solution, which was to use throw new PropagateResponseException($response);, described here: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Http/Index.html#migration

I suppose this issue can be closed/resolved, I guess the documentation could be expanded to explain the handling of status codes in a FE context, i.e. that status codes cannot be manipulated in the response object in Extbase controller actions?

Actions

Copy link

Updated by Christian Kuhn over 3 years ago

Yes and no: Indeed PropagateResponseException works. Be aware the exception is marked internal, though - we'll try to obsolete it again, you're on your own if you use it in your extension.
So the issue is valid since core currently does not provide a non-internal way for extensions to do such things. However, I'm not sure when and how core/extbase will solve it.

Actions

Copy link

Updated by Jarvis H over 3 years ago

Agreed, PropagateResponseException is only meant as a temporary solution.

Actions

Copy link

Updated by Torben Hansen about 3 years ago

I think this behavior may raise some confusion for extension developers. Actually I also expected, that the status code of the returned PSR-7 response object will be sent to the client, but actually as described in the issue, always HTTP status 200 was returned.

Another workaround to the problem is to hardly set a header with the expected status code - e.g. header(HttpUtility::HTTP_STATUS_404);

But actually I think we should try to handle this in some way, so it is possible in TYPO3 11 LTS to make use of the response code.

Actions

Copy link

Updated by Gerrit Code Review about 3 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/+/71014

Actions

Copy link

Updated by Gerrit Code Review about 3 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/+/71014

Actions

Copy link

#10

Updated by Gerrit Code Review about 3 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/+/71014

Actions

Copy link

#11

Updated by Gerrit Code Review about 3 years ago

Patch set 4 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/+/71014

Actions

Copy link

#12