omega8cc / boa

Barracuda Octopus Aegir 5.4.0
https://omega8.cc/compare
394 stars 75 forks source link

Images hosted on an AWS S3 bucket are handled as HTML by Nginx #1431

Open ghost opened 4 years ago

ghost commented 4 years ago

At first; I'm not sure if this is an issue which is caused by BOA, or that is might be an issue that has multiple causes.

Situation Before I start migrating the files to an S3, I've used the private file system for development. The private file system worked without any problems. Now I've installed the Flysystem and the Flysystem - S3 module to use an S3 bucket, instead of the private file system.

On my local machine with Nginx, everything works fine, except for the thumbnails (but that's another story). I can upload files to the bucket and read/retrieve them again when loading the files into the page (images for example).

When I deploy everything to a BOA server, the upload functionality still works like on my local machine, but reading image files is an issue. It looks like that Nginx is handling the images as an HTML file, instead of a PNG for example (see images below).

s3-local This is my local environment with the same image uploaded twice. One is hosted on S3 and the other one is still served from the private file system (to make sure that nothing is wrong with the image)

s3-boa This is the BOA environment with exact the same images and setup (uploaded twice, one from S3 and one from private file system)

As you can see, the image served from S3 on a BOA server responds with a 404 error code from Nginx and are marked with the type "html" instead of "png".

Things I've tried

Remarkable ZIP files (and I thought PDF files too) are working fine. So when I enter the flysystem path in the browser, it starts downloading the file. When I do the same for images, I encounter a 404.

omega8cc commented 4 years ago

Not sure if I follow, but if the images are hosted on AWS, aren't they served from AWS instead of via BOA based Nginx? If not, what would be the point? if they are served from AWS directly, then their MIME can't be associated with anything on the BOA Nginx side.

If the URL doesn't match, then AWS responds with 404 which is obviously HTML not image. That is expected but it means that something is misconfigured, but it's not related to MIME which Nginx sets for files it serves.

ghost commented 4 years ago

Thank you for replying on this issue.

The images and files are indeed hosted on AWS. They are served from AWS when the flysystem module tries to load them via a method that is similar to the private file storage method (it's using the path /_flysystem/s3 instead of /system/files). So the images are not served directly from AWS, but are loaded by the Flysystem module.

I'm sure the URL is matching and that the image exists. The most remarkable thing is that files (like ZIP and PDF) are working fine, but are handled via the same flow.

I'm not an expert when it comes to MIME being set from Nginx, but I can't figure out why files are working fine, but images are not.

ghost commented 4 years ago

I've just setup a clean LEMP stack with a fresh installation of the application. The bug does not exist on the LEMP stack (In other words; images loaded from AWS via the Flysystem module are working fine and have the correct MIME type).