skip to Main Content

I have a strange issue with artifacts in pictures delivered via apache2.4 to the web browser. Our comany uses a central picture storage for all the product images. This directory is mounted into the webserver under mnt/medamazonbild. I created a symbolic link, which points into the web directory under img/artikel. This worked and the folder is fully accessible.

But as soon as I request a picture from the directory via chrome or firefox under:

172.17.1.27/img/artikel/70399.jpg

the output is delivered with artifacts.

Apache delivers the picture with artifacts.

For test purposes I tried to deliver the image via PHP in image.php:

if (isset($_GET["img"])) {
    // get image name
    $img = filter_var($_GET["img"], FILTER_SANITIZE_STRING);

    // path of image with name and suffix
    $path = '/var/www/html/public/img/artikel/' . $img;

    header('Content-Type: image/jpeg');
    readfile($path);
}

The result is the image without artifacts as it should be:

The output with the readfile function delivers the expected image

I don’t want to process the image output for all the images with php, because I’m afraid of performance decreases. How can I get a solution for apache to deliver the images as expected? Where is the error?

Setup:

  • Ubuntu 18.04 LTS
  • Apache 2.4
  • Mounted directory with pictures under: mnt/medamazonbild
  • Symbolic link from mnt/medamazonbild into webroot img/artikel

2

Answers


  1. I have the same type of glitchs on my images.
    I’m using the official docker image php:7.3-apache Docker Hub
    To fix this issue I added EnableSendfile on to my .htaccess (I think it works the same as if you add it in your httpd.conf)

    Login or Signup to reply.
  2. I just had this exact same issue on a Kubernetes cluster at Azure (AKS).

    We updated from 1.16.X to 19.X.X recently, and images on our WordPress sites stopped working. Trying to open the image path in Chrome, it downloaded an corrupt file instead of showing the image.

    After one hole day of debugging, we made the following observations:

    • Serving images from anywhere but inside a mount worked as expected
    • We made sure the fileshare was mounted with the exact same permissions as folders and files outside the mount, where serving images where working
    • When looking at the headers (curl -X HEAD -I https://path) they where as expected
    • Images from the mount was altered upon download – it added some artifacts to the beginning of the image (something that looked like HTTP headers in plaintext) and when comparing the source code of the image, it seemed to contain some wrongly encoded content, make the image look like the one from OP

    The simple solution of adding EnableSendfile on to our .htaccess solved the problem – thanks a lot @botf!

    We don’t have any clue why (maybe some Apache experts can shed some light) but apparently Apache2 have some issues with reading the files from our mounts.
    We have other services on our AKS cluster running NGINX which are working fine.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search