Question

I have a real strange behavior when sending a zip archive containing a any type of file in symfony.
The problem is that the zip file, that I download from the browser contains an extra ‘bit’ at the beginning of the file.

Here’s my code:

$tmpFileName = tempnam("/tmp", "xb_");
$zip = new ZipArchive();
$zip->open($tmpFileName, ZipArchive::CREATE);
$zip->addFile('[directory_inside_webspace]/test.pdf', 'myTest.pdf');
$zip->close();
$this->getResponse()->clearHttpHeaders();
$this->getResponse()->setContent(file_get_contents($tmpFileName));
$this->getResponse()->setHttpHeader('Content-Type', 'application/zip');
$this->getResponse()->setHttpHeader('Content-Disposition', 'attachment; filename=archive.zip');
return sfView::NONE;

Now here’s what is strange. The temporary zip file under /tmp is fine. I can extract it without any problems.
But the file the browser sends to me is corrupt. When I open both of them in hex editor, the first few bytes look like:

working file:      50 4B 03 04 14 00 00 
corrupt file:   0A 50 4B 03 04 14 00 00

When I remove the addition ‘0A’ from the corrupt file I can open it without problems.
It’s now the exactly same file as the tmp file created in /tmp.

Did anyone had a behavior like this before?? I’m stucked at this problem for over 4 days now and I’m not able to find the error.
I use exactly the same code in another symfony module and it’s working in there. Any ideas ?

—–Update——

The problem wasn’t related to the zipArchive or setContent.
I had a query at the beginning of the function.

$bill = Doctrine::getTable('Bill')->find($request->getParameter('id'));

In the class ‘Bill.class.php’ in my doctrine model I had a blank line before

<?php

So when the class Bill was instantiated the new line was print to screen.

I just wonder why php doesn’t give an error message like ‘headers already send’ when sending the zip Archive to the browser.

Answer 1

0A is a newline character. Make sure there’s no newline before the <?php tag of all the files involved, and no newline after the ?> tag (unless you omit the closing tag, which is recommended).
The most probable culprit is the actions.class.php of the download action.