TYPO3 Core

(removed) Sorry, was BS from my side ...

I build an extension to demonstrate the problem.

Steps to reproduce the problem:¶

1. Install EXT:bug99534 from https://github.com/ghermens/bug99534.git or the attached file.
2. Include the TS template on an empty page.
3. Open this page in the browser.

Actual result¶

In TYPO3 11.5.22, the Content-Type header is set to 'text/html; charset=UTF-8'. The browser dumps the source of the file.

Expected result¶

Up to TYPO3 11.5.21, the Content-Type header is set to 'application/pdf'. The browser handles the file by opening an application assigned to this Content-Type or downloading the file.

Cause¶

With #99373, \TYPO3\CMS\Extbase\Core\Bootstrap->handleFrontendRequest() removes the Content-Type from the response not only for application/json, but for all types. The Content-Type is written to \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->setContentType() instead.
In \TYPO3CMS\Frontend\Http\RequestHandler->handle() the Content-Type is restored to the final response in line 171:

$response = $controller->applyHttpHeadersToResponse($response);

However, if config.disableCharset = 1 is set, \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->applyHttpHeadersToResponse() sets no Content-Type at all:

// Set header for charset-encoding unless disabled
if (empty($this->config['config']['disableCharsetHeader'])) {
    $response = $response->withHeader('Content-Type', $this->contentType . '; charset=' . trim($this->metaCharset));
}

Possible Solution¶

config.disableCharset = 1 should only disable the charset part of the Content-Type, i.e.:

// Set header for charset-encoding unless disabled
if (empty($this->config['config']['disableCharsetHeader'])) {
    $response = $response->withHeader('Content-Type', $this->contentType . '; charset=' . trim($this->metaCharset));
} else {
    $response = $response->withHeader('Content-Type', $this->contentType);
}

Workaround¶

With config.disableCharset = 0, the Content-Type is set to 'application/pdf; charset=utf-8'. The additional charset parameter seems to be no problem.
In TYPO3 12, disableCharset is removed (without deprecation?) anyway: #97550

But for TYPO3 11 this imho is a breaking change, which should not happen in a LTS version.

Throwing a PropagateResponseException as indicated by Chris Müller will work, too. This is also the cleanest solution as the stripped down target page is not needed at all.

Fixed in latest v12 LTS.