search

craftcms / cms

Build bespoke content experiences with Craft.
https://craftcms.com
Other
3.28k stars 635 forks source link

[4.x]: #13129

Closed Mixxey closed 1 year ago

Mixxey commented 1 year ago

What happened?

Description

Since we updated from 4.4.5 to 4.4.7.1 files uploaded to a local volume work fine in a logged-in browser but usually (not always, though) return 404 in incognito tabs, unknown browsers etc.

Steps to reproduce

  1. Upload file to https://hero-software.de/assets/data (or other local volume; file type doesn't matter) - I uploaded https://hero-software.de/assets/data/test.txt for testing

Volume settings: image image

  1. Check file while logged in
  2. Check file in incognito tab or random other browser

Expected behavior

The file is always displayed (we use this for Lottie JSON animations, but I also tested it with images and text files - same effect)

Actual behavior

The file often (but not always) returns a 404 image image

The problem occurs in prod and staging environment but not in local. I also updated Craft and plugins to the latest version today, which didn't fix the problem. I tried creating other local volumes before and after that update, which all show the same behavior (tested on staging).

Some help or advice would be much appreciated :)

Craft CMS version

Craft Pro 4.4.7.1

PHP version

8.0.28

Operating system and version

Linux 4.15.0-206-generic

Database type and version

MySQL 5.7.41

Image driver and version

Imagick 3.7.0 (ImageMagick 6.9.10-23)

Installed plugins and versions

i-just commented 1 year ago

Hi, thanks for reaching out. I can’t replicate it on a clean installation, but I wonder if this would still be the case if you specified a Base URL with an alias (that points to the base URL for this site) or an absolute path. For example: @web/assets/data or https://my-staging-site.com/assets/data (replace my-staging-site.com with the actual base URL for your staging site). Could you please try that in the staging environment (where you’re also experiencing this issue) and let me know if the problem persists?

Mixxey commented 1 year ago

Hey, thanks for getting back to me! Sadly, the ideas you proposed result in the same behavior. However, I looked into the commit history again, and I must correct my initial statement: the error occurred before the last update, so I guess it might be a coincidence that the oldest files work. Or at least I can't seem to find any other changes that might have caused this error.

i-just commented 1 year ago

Are you in a load-balanced environment by any chance?

Mixxey commented 1 year ago

Oh, yes we are.

i-just commented 1 year ago

Right. This will likely have something to do with your setup.

I assume that when you log in to admin, you are “locked” to a specific network in your load-balanced environment (e.g. via a sticky session). From the moment you log in, you are always routed to the same instances. However, when you log out, or that session expires, or when you use an incognito mode or a different browser, you might get connected to a different instance, and that instance might not have the file you uploaded via the Control Panel. This explains why you can sometimes view the file and sometimes not - it depends on where you’re routed via the load balancer.

I’d check that the location where the files are uploaded is available from all the load-balanced instances or if the replication scripts (if you’re using them) are working as expected. There can sometimes be a delay in files getting replicated across your network (again, it depends on your setup and configuration), so the files might not be available immediately but start working after some time has passed.

I hope this will help you (or your hosting provider) figure out how to fix this problem!