Bug #99534
closed
Content-Type forced to text/html when streaming file
0%
Description
I have an extbase action that streams a file like
/** @var \TYPO3\CMS\Core\Resource\FileReference $file */
$originalFile = $file->getOriginalResource()->getOriginalFile();
return $originalFile->getStorage()->streamFile(
$originalFile,
false
);
The target page is stripped down to the minimum:
config >
config {
disableAllHeaderCode = 1
disableBodyTag = 1
disableCharsetHeader = 1
disableLanguageHeader = 1
doctype = none
admPanel = 0
debug = 0
xhtml_cleaning = none
disablePrefixComment = 1
no_cache = 1
}
page >
page = PAGE
page {
10 = COA_INT
10 {
10 < tt_content.list.20.myext_downloadstream
}
}
This has worked up to TYPO3 11.5.21.
With TYPO3 11.5.22 the Content-Type header is forced to text/html.
I suspect #99373 to cause this, but can't find the exact reason.
The correct Content-Type is set if I comment line 185 of
TYPO3\CMS\Extbase\Core\Bootstrap->handleFrontendRequest(): $response = $response->withoutHeader('Content-Type');
Files
Updated by Chris Müller over 1 year ago
- Status changed from New to Needs Feedback
(removed) Sorry, was BS from my side ...
Updated by Gregor Hermens over 1 year ago
I build an extension to demonstrate the problem.
Steps to reproduce the problem:¶
- Install EXT:bug99534 from https://github.com/ghermens/bug99534.git or the attached file.
- Include the TS template on an empty page.
- 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.
Updated by Chris Müller over 1 year ago
- Status changed from Needs Feedback to New
Updated by JAKOTA Design Group GmbH 9 months ago
Hi, I believe this has been fixed with:
Updated by Benni Mack about 2 months ago
- Related to Bug #100189: Content-Type charset is now also added for application/binary Extbase responses added