0

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.

James Amner
  • 1
  • 1
  • Can you please show the code how the image is generated in the first place? Also, why do you store the file with `file_put_contents` when you want to deliver it to the client? – lxg Oct 09 '18 at 08:08
  • The file_put is just for me debugging now to check if the image is valid. I can get the code but it’s passed through about 3 controllers before saving unfortunately. Short version is that there’s a frontend webcontroller and a backend API and the image is being passed in binary form from the front into the API, where it’s validated, resized and stored on disk. I’d like to rewrite so that the API is serving the actual images directly, but no budget for a rewrite. The $imageData variable though is producing perfect image when passed to file_put, but if I curl the request url I get image with LF. – James Amner Oct 09 '18 at 11:45
  • Do responses from other controllers also produce an extra LF byte? – lxg Oct 09 '18 at 13:11
  • I’ll have to double check, every other response is JSON so it wouldn’t matter. I have found that just creating an empty response produces a response just with that new line. – James Amner Oct 10 '18 at 01:39
  • This sounds definitely like someone messed with the Symfony core code in your project. As it’s pretty old, I assume the `vendor/*` content has been commited to the repo, right? If so, please check in your VCS if any files have been modified by your party. – lxg Oct 10 '18 at 07:41

1 Answers1

0

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.

lxg
  • 12,375
  • 12
  • 51
  • 73
  • Thanks for your help, $imageData is file_get_contents(image_file) which is working fine. And file_put_contents($imageData) also produces a working image the LF being added must be added as the data is added to the Response class. I had suspicious that it was a new line error - I’ve run through all the classes written and used and no line errors, I’ve started looking at the classes in Symfony’s Response Class files but can’t issues there. I wouldn’t really know how to apply quick and dirty fix in this context, I can’t strip first byte before the response is made as that’s valid data. – James Amner Oct 09 '18 at 10:11