http://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692015-08-21T08:39:27ZTYPO3 ForgeTYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2727432015-08-21T08:39:27ZFrans Sarisfranssaris@gmail.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Needs Feedback</i></li></ul><p>Also when you put a <code>exit;</code> right after the dump?</p>
<p>We use this in <a class="external" href="https://github.com/beechit/fal_securedownload/blob/master/Classes/Hooks/FileDumpHook.php">https://github.com/beechit/fal_securedownload/blob/master/Classes/Hooks/FileDumpHook.php</a> and can remember any issues. But maybe that is due the fact it used in the eId context.</p>
<p>Can you determine where the first header is send?</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2727482015-08-21T09:18:12ZTorben Hansenderhansen@gmail.com
<ul></ul><p>Adding <code>exit;</code> does not solve the problem. I believe, that the first header gets send by <code>ResourceStorage->dumpFileContents()</code>, because if I comment out the header sent by the compression utility, then the download gets triggered. Here the next problem appears, which is a following problem of the compression.</p>
<p>When compression is enabled, the <code>ResourceStorage->dumpFileContents()</code> actually sends the correct header information for the file, but the compression messes this up. I'll dump an .ics file and <code>ResourceStorage->dumpFileContents()</code> sets the mime type correctly to "text/calendar". When compression is enabled, this mime type sent in the headers does'nt match the mime type of the sent file, so the browser refuses to download the file.</p>
<pre>
Resource interpreted as Document but transferred with MIME type text/calendar
</pre>
<p>IMO dumpFileContents() should ignore FE compression and just dump the file as it is.</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2727622015-08-21T10:32:19ZFrans Sarisfranssaris@gmail.com
<ul></ul><p>If I read the code correct the compression is disabled in <code>$storage->dumpFileContents</code>. Further are the headers send by the dumpFileContents the last headers send. Before the file is dumped the output buffer is cleared and after that no compression is set. See <code>ResourceStorage::dumpFileContents()</code>.</p>
<p>So what is already outputted before you call <code>$storage->dumpFileContents</code>?</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2727882015-08-21T13:31:21ZTorben Hansenderhansen@gmail.com
<ul></ul><p>My code is really simple.</p>
<p>I have an ExtBase controller, where I have the following action (simplyfied).</p>
<pre>
public function downloadAction() {
$storage = $this->resourceFactory->getDefaultStorage();
$file = $storage->getFile('test.jpg');
$storage->dumpFileContents($file, TRUE, 'test-filename.jpg');
return FALSE;
}
</pre>
<p>This all works well, when FE compression is disabled. When I enable FE compression, the exception is thrown. I get the following headers as a response from the server</p>
<pre>
HTTP/1.1 200 OK
Date: Fri, 21 Aug 2015 11:17:39 GMT
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.2a DAV/2 PHP/5.6.9
X-Powered-By: PHP/5.6.9
Expires: 0
Last-Modified: Fri, 21 Aug 2015 11:17:39 GMT
Cache-Control: ''
Pragma: no-cache
Content-Disposition: attachment; filename="event_1.ics"
Content-Length: 281
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/calendar;charset=UTF-8
</pre>
<p>For me, everything seems fine except the <code>Content-Encoding: gzip</code> header. The <code>Content-Length</code> header is ok and outputs the content length for the uncompressed file. So I wonder where this <code>Content-Encoding: gzip</code> header comes from.</p>
<p>Does the ExtBase action send the <code>Content-Encoding: gzip</code> header and if yes, can it be avoided?</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2818232015-10-15T19:54:55ZTorben Hansenderhansen@gmail.com
<ul></ul><p>Any idea how to solve this issue? It seems dumpFileContents for the frontend context only works correct, when FE compression is disabled. Any ideas for a workaround?</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2857832015-11-12T17:06:55ZMathias Schreibermathias.schreiber@typo3.com
<ul><li><strong>Target version</strong> deleted (<del><i>next-patchlevel</i></del>)</li></ul> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=2980762016-02-26T16:31:19ZAlexander Opitzopitz.alexander@googlemail.com
<ul><li><strong>Status</strong> changed from <i>Needs Feedback</i> to <i>New</i></li><li><strong>Target version</strong> set to <i>next-patchlevel</i></li></ul> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=3362412017-07-04T17:59:08ZSven Teuberteuber@stibes.de
<ul><li><strong>TYPO3 Version</strong> changed from <i>6.2</i> to <i>7</i></li></ul><p>Issue is still present in TYPO3 7.6.19 LTS (bump)</p>
<p>The Content-Encoding: gzip header Torben mentioned, which is the source of the problem, seems to be set by PHP when zlib.output_compression_level is set in \TYPO3\CMS\Frontend\Http\RequestHandler::initializeOutputCompression. I guess it should be removed before dumping a file with dumpFileContents().</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=3962182019-03-07T08:48:46ZSusanne Moogsusanne.moog@typo3.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Needs Feedback</i></li></ul><p>Can you check this behaviour with 9? Request/Repsonse handling got lots of changes, it might be fixed.</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=3963802019-03-09T07:36:58ZTorben Hansenderhansen@gmail.com
<ul></ul><p>Yes I verified this with TYPO3 9.5 and the problem is still valid, since the method <code>dumpFileContents</code> is still the same.</p>
<p>But anyway, <code>dumpFileContents</code> is deprecated since V9, so I tried to migrate to <code>streamFile</code> instead. Migration (especially using the functionality in an Extbase extension) is not really easy/possible(?), since the successor for <code>dumpFileContents</code> works different. <code>dumpFileContents</code> streams the file directly to the client using output buffering, but <code>streamFile</code> returns a PSR-7 response object.</p>
<p>As far as I know, Extbase has its on request/response handling, so you can't just return the PSR-7 response object in an Extbase action to stream the file to the client. Also I did not find something to emit the PSR7 response in Extbase and a search on Slack resulted in one single person asking for help about this topic, but with no response.</p>
<p>In TYPO3 backend, <code>application::sendResponse</code> is used to emit a PSR-7 response object. I implemented a similar method in my Extbase controller to force output of the content of the PSR-7 response, but honesty this feels dirty (see code below).</p>
<pre>
public function downloadAction()
{
$storage = $this->resourceFactory->getDefaultStorage();
$file = $storage->getFile('test.jpg');
$response = $storage->streamFile($file, true, 'test-filename.jpg');
$this->sendResponse($response);
exit();
}
protected function sendResponse($response)
{
if (!headers_sent()) {
if (http_response_code() === 200) {
header('HTTP/' . $response->getProtocolVersion() . ' ' . $response->getStatusCode() . ' ' . $response->getReasonPhrase());
}
foreach ($response->getHeaders() as $name => $values) {
header($name . ': ' . implode(', ', $values));
}
}
$body = $response->getBody();
echo $body->__toString();
}
</pre>
<p>Is there a recommended way to emit PSR-7 response objects in Extbase? Or is there maybe something I am missing?</p> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=3964302019-03-09T19:00:54ZRiccardo De Contardierredeco@gmail.com
<ul><li><strong>Status</strong> changed from <i>Needs Feedback</i> to <i>New</i></li></ul> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=3983642019-04-17T23:40:54ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>next-patchlevel</i> to <i>Candidate for patchlevel</i></li></ul> TYPO3 Core - Bug #69223: dumpFileContents does not work when ['FE']['compressionLevel'] > 0http://forge.typo3.org/issues/69223?journal_id=4190392020-03-14T16:30:18ZBenni Mackbenni@typo3.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>@Torben you can throw an Exception (ImmediateResponseException) that contains a PSR-7 response that is the way that is <em>currently</em> possible but not clean (hopefully we'll get there).</p>
<p>I hope this information helps. I will close this issue - feel free to re-open if you want us to do something else code-wise. I have this topic (Extbase + PSR7 Response) on the radar for v11 anyway.</p>