TYPO3 Core

This imho is a bigger feature, that should not be tackled in the stabilization sprint.

With PSR-7 in, we most likely need to reconsider even more parts of the reques/response handling.

Afaik Benni said he saw a chance for a temporary workaround to make HTTP-status-codes set from an extbase-extension work again (simply put: not override the status-header from the response-object). If possible that would be great, if not (for 7.4) then fine for the moment. But it's something that worked in the past and now broke!

The response-object (for psr-7) added with c048cede7a402275e501d7a86cb560995f29360b sends the status in the header, which defaults to 200.

If in typo3/sysext/extbase/Classes/Mvc/Web/Response.php you use setStatus() to set a different status-code through an extbase-plugin, extbase will output that as the header. If I put an immediate stop after the extbase-output I get the status. If however the request finishes the normal way, it seems to get overwritten with 200 again.

You are right that typo3/sysext/core/Classes/Core/Bootstrap.php checks for headers_sent(). But I assume the headers are just set and not yet sent to the browser, as no output was done inbetween. The output from extbase is passed back to the CMS-core to be output - it's just that headers were already set.

Maybe a possible hack would be to make Extbase send its output itself after setting the headers (and returning an empty string to the Bootstrap). Thus headers_sent() would then be true and Bootstrap wouldn't try to write headers itself. (I can't test that right now, but could later.)

I got it now.

The status header is ALWAYS overridden by the PSR-7 implementation.

Markus Klein wrote:

I'm not sure how to reproduce this issue, since the Bootstrap code checks for headers_sent(), hence if Extbase sent the headers, it will not do anything.

Using the header() function does not mean that PHP does send the headers! Headers are sent once the first body line needs to be sent, so this check under normal conditions always is true.

Steps to reproduce:

Create an Extbase action that only does a

$this->redirect('anotherAction');

use curl to check the response of that:

curl -s -D - 'http://test.t3/url/to/redirect/action/' -o /dev/null

You will see a Location: header but with a 200 response code, which is invalid. We did not recognize this as browser seem to be graceful and redirect anyway.

Ah ok, that makes sense, thanks for investigation.

I see no other way than hacking the psr-7 objects into extbase.

Does

if (headers_sent() || count(headers_list()) > 0) {}

thanks Alex!

For documentation purposes:
The Patch (42049) introduced a regression: https://forge.typo3.org/issues/68595 and therefore was reverted.

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42122

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42122

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42122

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42122