Bug #94533

Extbase controller response status not working

Added by Jarvis H 3 months ago. Updated 15 days ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2021-07-10
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
11
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
}
#1

Updated by Jarvis H 3 months ago

  • Description updated (diff)
#2

Updated by Jarvis H 3 months ago

  • Description updated (diff)
#3

Updated by Christian Kuhn 3 months 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.

#4

Updated by Jarvis H 3 months 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?

#5

Updated by Christian Kuhn 3 months 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.

#6

Updated by Jarvis H 3 months ago

Agreed, PropagateResponseException is only meant as a temporary solution.

#7

Updated by Torben Hansen about 1 month 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.

#8

Updated by Gerrit Code Review about 1 month 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

#9

Updated by Gerrit Code Review about 1 month 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

#10

Updated by Gerrit Code Review about 1 month 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

#11

Updated by Gerrit Code Review about 1 month 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

#12

Updated by Torben Hansen about 1 month ago

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

Updated by Benni Mack 15 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF