Symfony 2.1.11 Image Data Response adding additional byte to start of response body

Question

I'm trying to resurrect an old Symfony 2.11 project for a client who hasn't the budget for a re-write to upgrade it to something more modern. One of the routes provides raw image data in it's response

$resp = new Response($imageData);
file_put_contents('./image.jpg', $imageData);
$resp->headers->set('Content-Type', $mime);
return $resp;

The image saved to image.jpg is valid, opens and works as expected, but when making a request the response returns the same data, but with one additional first byte - byte in hex 0A - how can I prevent this additional byte being added as it's stopping browsers from rendering the image.

Using Symfony 2.1.11, willing to look at upgrading if it's not going to take too long or cause too many problems, but it's a pretty massive project so I'm afraid of the fallout of upgrading when it was apparently working at one point based on it's current configuration.

Answer 1

0A is a LF or \r character, that is a newline (or, actually: a line feed) on Windows systems.

As I don’t know how the image data is generated, I’ll have to make assumptions here: Sometimes, extra LF’s pop up when somebody has edited a PHP file and added an extra newline before the opening PHP tag by accident. But in that case, you would get a warning such as Headers already sent … as soon as you try to send the response. So the extra line seems to have snuck into $imageData in some different way. [I’ll update this part as soon as the image generation code is added to the question.]

A dirty workaround would be to ltrim the 0A from $imageData before further processing, though I would recommend trying to find the place where the extra line is added to the image data and fix it.

Answer 2

This issue is the same as the one reported here : Corrupted ZipArchive after setContent() in php symfony The root cause is probably a new line outside <?php ?> tags. This common issue in PHP is why it is advised to not use the closing tag when not necessary.