You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there,
I've discovered an issue when testing my environment, which uses AWS S3 for storage. I found that images were being requested twice in the console, and the results were that the images would not load on the front-end.
In the Accepted Answer, i was able to implement the Workaround #1, using Cloudfront and assigning a Custom Origin Headers value. This works, but i think this solution would be restrictive to some folks.
I recommend implementing the Alternative Hackaround #2 in the application itself.
Thanks
The text was updated successfully, but these errors were encountered:
Hm, I couldn't reproduce it with the DigitalOcean S3 equivalent but even if the behavior is only AWS specific, I don't think that the second workaround is applicable in our case.
An image could be requested multiple times because it is displayed in multiple places and/or the application is loading the image in the background to check its width and height. So we heavily relies on the internal browser caching and by adding different query parameters to the requests will force the browser to download the image multiple times.
For now, I'll close the issue, but I'll make sure to link it in the the future S3 setup doc.
Hi there,
I've discovered an issue when testing my environment, which uses AWS S3 for storage. I found that images were being requested twice in the console, and the results were that the images would not load on the front-end.
After some digging, i came across this thread, which explains the issue quite clearly.
https://serverfault.com/questions/856904/chrome-s3-cloudfront-no-access-control-allow-origin-header-on-initial-xhr-req/856948#856948
In the Accepted Answer, i was able to implement the Workaround #1, using Cloudfront and assigning a Custom Origin Headers value. This works, but i think this solution would be restrictive to some folks.
I recommend implementing the Alternative Hackaround #2 in the application itself.
Thanks
The text was updated successfully, but these errors were encountered: